Re: [Gnumed-devel] Observations & questions about GNUmed

[Karsten Hilbert]

On Sun, Oct 07, 2007 at 10:06:01AM -0700, Jim Busser wrote:

> Someone I believe to have a lot of postgres experience, who has been having a 
> look at GNUmed, welcomed me to pass his observations and questions along for 
> comment. Karsten had earlier responded about GNUmed not yet having many tests 
> of 
> its software but I don't know that the first two observations have been 
> previously submitted or commented on:

> Looking at the gnumed server code I find it both brilliant and questionable 
> at 
> the same time.
I am sure that's true.

> 1) The use of XMIN for detecting concurrent updates. In  general using any 
> system column from another piece of infrastructure is fragile. The semantics 
> of 
> XMIN is part of postgresql it should not be part of gnumed. The postgresql 
> developers are free to change the semantics of XMIN as they wish. They are 
> saving 1 integer column, or timestamp column to do this properly. Is it worth 
> it 
> ?
I fully agree with this criticism.

The reason why we haven't had problems with depending on it
is that the intent of GNUmed and PostgreSQL seem to overlap
entirely, namely to segregate transactions from one another.
This can, indeed, change for the worse during PostgreSQL
development. It did change recently when SAVEPOINTS were
introduced, which, however, didn't concern us since we never
assumed increasing, let alone consecutive, XMIN values. All
we rely on is that they *change* when a transaction commits.
We would only really have a problem if XMIN went away
without any replacement. Which is unlikely (though not
impossible, see row OIDs) for two reasons:

- PG doesn't expose XMIN anymore
        - that would be against PGs track record

- PG doesn't *have* XMIN anymore
        - it still needs *something* to distinguish transactions

I am open to accept patches to improve this situation. It
would require one additional column on all our tables and an
UPDATE rule on each table, too.

> 2) Using updateable views is also very "correct"
We don't use them except in one case I believe. And even
that isn't really used in the frontend code. I agree there
isn't really a tangible advantage to using them currently
(as PG doesn't automatically support them yet).

> however has anyone tested this 
> on a huge database ? All those foreign keys are wonderful, but will take 
> forever 
> to rebuild.
Can you elaborate on the scenario you are concerned about ?

> I've seen foreign key checks on a restore take a few hours to run 
> through.
Sure, but if the time to do that isn't there your
backup/fallback strategy needs rethinking. One might need a
replicated server if downtime is that critical.

> 3) Where are the test cases ? Are there any regression tests ?
Not really. We sorely lack regression tests for the backend
schema per se. I am not even sure how to write them. Help
would be greatly appreciated.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346