On Thu, Jul 2, 2015 at 3:59 AM, Etsuro Fujita <fujita.ets...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
