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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE
Дата
Msg-id CA+TgmoYG3-9wBHTjMs43oSvJfxVsPAm4obfHbp5tscnmTyjy_w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Список pgsql-hackers
On Thu, Jul 2, 2015 at 3:59 AM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:
> 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.

Does 385f337c9f39b21dca96ca4770552a10a6d5af24 make any difference to
the issue described here?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Patch to improve a few appendStringInfo* calls
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: ToDo list update for BRIN indexes