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