[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Comments on 0.2

From: Syan Tan
Subject: Re: [Gnumed-devel] Comments on 0.2
Date: Thu, 22 Jun 2006 09:25:37 +0800

maybe a redundant application layer consistency mechanism like middleware vector timestamps is

needed to avoid playing catchup all the time  ;)

On Thu Jun 22 4:23 , Tim Churches sent:

Ian Haywood wrote:
> Tim Churches wrote:
>> Karsten Hilbert wrote:
>>> On Tue, Jun 20, 2006 at 10:38:29PM +1000, Tim Churches wrote:
>>>> What is wrong with just using a transaction. If the row is locked by
>>>> another transaction writing to it, then the transaction will abort. No
>>>> need to mess around with explicit row locks, is there?
> Okay, let's think about this. We all accept the need for XMIN, it's explicit locking
> we are querying.
> Imagine two transactions running in parallel. Postgres forces them to serialize,
> (randomly if they hit the server at *exactly* the same time)
> Both do
> UPDATE foo SET A=B,C=D WHERE pk=123 and xmin=456;
> If we are in read-committed mode, one query sees the result of the other (made to wait if necessary),
> and so fails (Cursor.rowcount=0) as xmin doesn't match anymore.
> In serialisation mode, they don't see each others results, instead one will fail
> with a serialisation error, and forced to try again, whereupon it will fail
> (as it has now seen the results of the other)
> The docs state that UPDATE and SELECT FOR UPDATE operate in the same way.


One other thought: is it wise to use xmin as the row "state" identifier?
We've been stung by our use of OIDs to identify updated rows - user
access to the OID column is now deprecated in PG 8.1 and will disappear
entirely in future versions. Maybe a hash on the data read originally
from the row might be better, and that would also work where data is
read from many different tables to form the patient "row" object by your

Tim C

Gnumed-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]