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 [EMAIL PROTECTED]> ----- > >> Subject: Re: [GENERAL] XMIN semantic at peril ? >> >> Karsten Hilbert [EMAIL PROTECTED]> 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 >[email protected] >http://lists.gnu.org/mailman/listinfo/gnumed-devel _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
