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

On Thu, Jul 2, 2015 at 3:59 AM, Etsuro Fujita
<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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