| From: | Marko Tiikkaja <marko(at)joh(dot)to> |
|---|---|
| To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE |
| Date: | 2015-07-02 07:27:29 |
| Message-ID: | 5594E7E1.60107@joh.to |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro HORIGUCHI | 2015-07-02 07:31:48 | Re: Asynchronous execution on FDW |
| Previous Message | Amit Langote | 2015-07-02 07:16:30 | Re: Support for N synchronous standby servers - take 2 |