Re: [GENERAL] XMIN semantic at peril ?

2007-10-18 Thread Karsten Hilbert
On Thu, Oct 11, 2007 at 12:03:47PM -0400, Tom Lane wrote: If in the meantime another writer changed the data we originally read we would detect that by xmin having changed hence no row to be updated. So, yes, there is a *tiny* failure condition: Hmm. I think the failure condition is

[GENERAL] XMIN semantic at peril ?

2007-10-11 Thread Karsten Hilbert
Hi all, we use XMIN in our application (http://wiki.gnumed.de) as a lightweight database-provided data-changed marker in a cross-transaction optimistic locking scheme. The one characteristic of XMIN we rely on in this scheme is that XMIN changes when a (writing) transaction commits successfully.

Re: [GENERAL] XMIN semantic at peril ?

2007-10-11 Thread Tom Lane
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

Re: [GENERAL] XMIN semantic at peril ?

2007-10-11 Thread Karsten Hilbert
On Thu, Oct 11, 2007 at 10:44:17AM -0400, Tom Lane wrote: 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? Personally, yes, no problem and thanks for it :-)) Karsten -- GPG key ID

Re: [GENERAL] XMIN semantic at peril ?

2007-10-11 Thread Karsten Hilbert
On Thu, Oct 11, 2007 at 04:18:30PM +0100, Filip Rembiałkowski wrote: Subject: Re: [GENERAL] XMIN semantic at peril ? 2007/10/11, Tom Lane [EMAIL PROTECTED]: 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

Re: [GENERAL] XMIN semantic at peril ?

2007-10-11 Thread Karsten Hilbert
On Thu, Oct 11, 2007 at 10:44:17AM -0400, Tom Lane wrote: 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. I figured as much but I'm

Re: [GENERAL] XMIN semantic at peril ?

2007-10-11 Thread Filip Rembiałkowski
2007/10/11, Tom Lane [EMAIL PROTECTED]: 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? Well, at least not in all aspects, if I may cut in. (from http://www.gnumed.org/) error insert

Re: [GENERAL] XMIN semantic at peril ?

2007-10-11 Thread Tom Lane
Karsten Hilbert [EMAIL PROTECTED] writes: On Thu, Oct 11, 2007 at 10:44:17AM -0400, Tom Lane wrote: One question I'd have though is whether freezing of old tuples is likely to confuse your app. Well, what we do is this: - read row including XMIN - do some UI stuff without open transactions

Re: [GENERAL] XMIN semantic at peril ?

2007-10-11 Thread Erik Jones
On Oct 11, 2007, at 11:03 AM, Tom Lane wrote: Karsten Hilbert [EMAIL PROTECTED] writes: On Thu, Oct 11, 2007 at 10:44:17AM -0400, Tom Lane wrote: One question I'd have though is whether freezing of old tuples is likely to confuse your app. Well, what we do is this: - read row including

Re: [GENERAL] XMIN semantic at peril ?

2007-10-11 Thread Tom Lane
Erik Jones [EMAIL PROTECTED] writes: If the query is always based on a primary key + XMIN, and since vacuum is the only thing that sets FrozenTransactionId, would it be unsane to change the update to - update row with ... where pk=... and XMIN IN (old_xmin_from_read, FrozenTransactionId)

Re: [GENERAL] XMIN semantic at peril ?

2007-10-11 Thread Karsten Hilbert
On Thu, Oct 11, 2007 at 01:48:10PM -0400, Tom Lane wrote: If the query is always based on a primary key + XMIN, It is. and since vacuum is the only thing that sets FrozenTransactionId, would it be unsane to change the update to - update row with ... where pk=... and XMIN IN