Re: Tracking row updates - race condition
От | Alex Adriaanse |
---|---|
Тема | Re: Tracking row updates - race condition |
Дата | |
Msg-id | 4249758F.1050101@alexandcarmen.com обсуждение исходный текст |
Ответ на | Re: Tracking row updates - race condition (Harald Fuchs <use_reply_to@protecting.net>) |
Список | 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 по дате отправления: