[Top][All Lists]

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

Re: [Gnumed-devel] Comments on 0.2

From: Tim Churches
Subject: Re: [Gnumed-devel] Comments on 0.2
Date: Thu, 22 Jun 2006 04:23:52 +1000
User-agent: Thunderbird (Windows/20060516)

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

reply via email to

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