Re: [Gnumed-devel] Comments on 0.2

[Ian Haywood]

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.

Ian