Re: Tracking row updates - race condition - Mailing list pgsql-general

From Alex Adriaanse
Subject Re: Tracking row updates - race condition
Date
Msg-id 4249758F.1050101@alexandcarmen.com
Whole thread Raw
In response to Re: Tracking row updates - race condition  (Harald Fuchs <use_reply_to@protecting.net>)
List pgsql-general
Harald Fuchs wrote:

>In article <4248E1AE.8090404@alexandcarmen.com>,
>Alex Adriaanse <alex@alexandcarmen.com> writes:
>
>
>>Thanks for the input everyone.  I think Harald's approach will work
>>well...
>>
>>
>
>I'm not so sure anymore :-(
>
>Consider something like that:
>
>UPDATE tbl SET col1 = 1 WHERE col2 = 1;
>UPDATE tbl SET col1 = 2 WHERE col2 = 1;
>
>with not much time inbetween.  By using NULL temporarily, you destroy
>the ordering.  The client won't miss an UPDATE, but it might execute
>the second one before the first.  Neither my nor your idea appear to
>take care of that.
>
>
>
Maybe I'm missing something, but I don't really see the problem.  If
that second statement is executed before the transaction containing the
first statement is committed, wouldn't the second statement block until
the first statement is committed?  If the first one is committed before
the second statement is executed, then I don't see how the client will
see the updates out-of-order.

Alex



pgsql-general by date:

Previous
From: dharana
Date:
Subject: Unable to restore table oids from pg_dump
Next
From: Devrim GUNDUZ
Date:
Subject: 8.0.2beta1 RPMs