Re: Tracking row updates - race condition

From: Alex Adriaanse <alex(at)alexandcarmen(dot)com>
To: hf1122x(at)protecting(dot)net
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Tracking row updates - race condition
Date: 2005-03-29 15:34:39
Message-ID: 4249758F.1050101@alexandcarmen.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Harald Fuchs wrote:

>In article <4248E1AE(dot)8090404(at)alexandcarmen(dot)com>,
>Alex Adriaanse <alex(at)alexandcarmen(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Devrim GUNDUZ 2005-03-29 15:55:09 8.0.2beta1 RPMs
Previous Message Peterson, Bjorn 2005-03-29 15:04:56 Zombie processes