From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Oliver Seemann <oseemann(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Update with subselect sometimes returns wrong result |
Date: | 2013-12-19 00:58:08 |
Message-ID: | 20131219005808.GI11006@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andres Freund escribió:
> On 2013-12-18 19:13:43 -0300, Alvaro Herrera wrote:
> > I'm not sure about the added assert that the tuple cannot possibly be
> > locked. I fear cursors provide strange ways to access at tuples.
>
> I don't see how, the EPQ machinery should have ensured we're looking at
> the most recent version. Also, pretty fundamentally, we have to be the
> only locker, otherwise the optimization wouldn't be applicable in this
> way.
EPQ works funny with cursors in the WHERE CURRENT OF stuff; the fact
that it behaves differently in FOR UPDATE case than when there's no
locking clause makes this whole thing pretty misterious.
Anyway I think this whole optimization can be formulated more clearly if
we separate the case into its own block by checking
XidIsCurrentTransaction instead of cramming it into the XidIsInProgress
case as the original is doing; see attached.
Any ideas on possible tests for this stuff? Nothing comes to mind that
doesn't involve pageinspect ...
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-Optimize-updating-a-row-that-s-locked-by-same-xact.patch | text/x-diff | 4.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | katsumata.tomonari | 2013-12-19 02:57:26 | BUG #8686: Standby could not restart. |
Previous Message | Andres Freund | 2013-12-18 22:39:44 | Re: Update with subselect sometimes returns wrong result |