Re: Update with subselect sometimes returns wrong result

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

In response to

Responses

Browse pgsql-bugs by date

  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