Re: Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE
Date
Msg-id 5594E7E1.60107@joh.to
Whole thread Raw
In response to Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
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.


.m



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Asynchronous execution on FDW