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 по дате отправления:

Предыдущее
От: dharana
Дата:
Сообщение: Unable to restore table oids from pg_dump
Следующее
От: Devrim GUNDUZ
Дата:
Сообщение: 8.0.2beta1 RPMs