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

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