From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Marko Tiikkaja <marko(at)joh(dot)to>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE |
Date: | 2015-07-02 07:59:14 |
Message-ID: | 5594EF52.10207@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2015-07-02 08:30:44 | Re: Refactoring speculative insertion with unique indexes a little |
Previous Message | Michael Paquier | 2015-07-02 07:37:20 | Re: pg_basebackup and replication slots |