Re: Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE
Дата
Msg-id 5594EF52.10207@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Hi Marko,

On 2015/07/02 16:27, Marko Tiikkaja wrote:
> On 7/2/15 9:15 AM, Etsuro Fujita wrote:
>> While working on the foreign-join-pushdown issue, I noticed that in READ
>> COMMITTED isolation level it's possible that the result of SELECT ...
>> ORDER BY ... FOR UPDATE is not sorted correctly due to concurrent
>> updates that replaced the sort key columns with new values as shown in
>> the below example.  That seems odd to me.  So, I'd like to propose
>> raising an error rather than returning a possibly-incorrect result for
>> cases where the sorted tuples to be locked were modified by concurrent
>> updates.

> I don't like the idea of READ COMMITTED suddenly throwing errors due to
> concurrency problems.  Using FOR UPDATE correctly is really tricky, and
> this is just one example.  And a documented one, at that, too.

Ah, you are right.  I'll withdraw this.  Sorry for the noise.

Best regards,
Etsuro Fujita



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_basebackup and replication slots
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Refactoring speculative insertion with unique indexes a little