Re: [Gnumed-devel] address@hidden: Re: [GENERAL] XMIN semantic at peril ?]

[Syan Tan]

you wouldn't need xmin checking if more effort was made by the postgresql people
to cater
for caching interactive clients , which would  be a significant group of pg 
customers
i would have thought. e.g something like using savepoints, atomic commit/resume
transaction , the ability to read committed in order to reload , and the ability
to poll for change notification, so that you don't need another thread to listen
for notified changes, and you can use read committed to refresh cached values.
Too much to ask for ? 

On Thu Oct 11 17:22 , Karsten Hilbert  sent:

>I'd think this settles things for now:
>
>----- Forwarded message from Tom Lane address@hidden> -----
>
>> Subject: Re: [GENERAL] XMIN semantic at peril ? 
>> 
>> Karsten Hilbert address@hidden> writes:
>> >   How likely is XMIN (or equivalent) to become invisible to
>> >   SQL level user space ?
>> 
>> No one has suggested this.  I suppose the argument could be made that
>> the system columns are an unwarranted intrusion on users' column
>> namespace, but we'd probably handle that by demoting them to
>> second-class citizens, not hiding them entirely --- there are far too
>> many apps that rely on ctid, for instance, and I think some that are
>> doing like you do with xmin.  So as long as you don't create a user
>> column named xmin in your tables, you could expect to access the system
>> column.
>> 
>> >   How likely is XMIN (or equivalent) to NOT change on each
>> >   successful (write) transaction commit anymore ?
>> 
>> No chance of that, unless we abandon MVCC for something else, which
>> again seems highly unlikely.
>> 
>> One question I'd have though is whether "freezing" of old tuples is
>> likely to confuse your app.  That process might get more aggressive
>> in the future (it already is more aggressive in 8.2 than before,
>> depending on where vacuum_freeze_min_age is set).
>> 
>> The only argument you cited that seems impressive to me is the one
>> about it being a Postgres-ism.  Are you willing to have GNUmed tied
>> tightly to Postgres?
>> 
>>                      regards, tom lane
>
>----- End forwarded message -----
>
>-- 
>GPG key ID E4071346 @ wwwkeys.pgp.net
>E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
>
>_______________________________________________
>Gnumed-devel mailing list
>address@hidden
>http://lists.gnu.org/mailman/listinfo/gnumed-devel