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
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 |