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

[Karsten Hilbert]

On Tue, Oct 09, 2007 at 07:18:07AM -0400, Dave Cramer wrote:

>>> Yeah, I'd have to agree with that adage. Of course one could argue that 
>>> XMIN is a premature optimization.
>>
>> It is not (intended as) an optimization at all but rather a
>> mechanism to detect imminent semantic corruption.
>>   
> I view it as optimization since it avoids a column
Oh, OK, I wasn't thinking about the diskspace side of
things. Under that point of view, yes, it's an optimization,
which, however, played no role in the design decision.

>>> as far as postgresql goes the new HOT patch comes dangerously close to 
>>> changing the semantics of XMIN.
>>>     
> I said dangerously close. It doesn't change the semantics but postgresql is 
> developing faster than it has in the past
I know, I know. I do acknowledge that it has potential to
become a problem somewhere down the line.

>> part of the very root of MVCC tuple visibility rules. The
>> only real danger would be if *user* visibiity of that change
>> indicator goes away so we cannot use it anymore. This is
>> highly unlikely given PGs track record of exposing more
>> rather than less state information over the years.
> oid's are now gone by default in user tables ....
Sure, as I pointed out earlier in this thread.

> Use either a version row or a timestamp row
As I said: I do know how to solve it technically. And, too,
I am open for patches.

> and implement optimistic locking
>
> http://www.agiledata.org/essays/concurrencyControl.html
Well, see, that's the difference between a doctor and an IT
person: I know what I need and you know what it's called.

So, what we do with XMIN is

        optimistic locking with
        marking the source with a unique identifier

the latter of which comes on the cheap by use of XMIN. We
could replace XMIN with a real column which would then
require update rules or rather triggers on all affected
tables. A missing column on a table would be detected by the
business object code (since it fails to read the column).

As I said: I am open to patches.

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