Re: 9.3 reference constraint regression

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Daniel Wood <dwood(at)salesforce(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: 9.3 reference constraint regression
Date: 2013-12-16 17:36:23
Message-ID: 20131216173623.GJ12902@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera wrote:

> The fix for the immediate bug is to add some code to HTSU so that it
> checks for locks by other transactions even when the tuple was created
> by us. I haven't looked at the other tqual routines yet, but I imagine
> they will need equivalent fixes.

This POC patch changes the two places in HeapTupleSatisfiesUpdate that
need to be touched for this to work. This is probably too simplistic,
in that I make the involved cases return HeapTupleBeingUpdated without
checking that there actually are remote lockers, which is the case of
concern. I'm not yet sure if this is the final form of the fix, or
instead we should expand the Multi (in the cases where there is a multi)
and verify whether any lockers are transactions other than the current
one. As is, nothing seems to break, but I think that's probably just
chance and should not be relied upon.

Attached are two isolation specs which illustrate both the exact issue
reported by Dan, and a similar one which involves an aborted
subtransaction having updated the second version of the row. (This
takes a slightly different code path.)

As far as I can tell, no other routine in tqual.c needs to change other
than HeapTupleSatisfiesUpdate. The ones that test for visibility
(Dirty, Any, Self) are only concerned with whether the tuple is visible,
and of course that won't be affected by the tuple being locked; and
HeapTupleSatisfiesVacuum is only concerned with the tuple being dead,
which similarly won't.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
danwood2.spec text/plain 1.2 KB
danwood.spec text/plain 1.1 KB
local-updater.patch text/x-diff 1.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-12-16 17:41:43 planner missing a trick for foreign tables w/OR conditions
Previous Message Tom Lane 2013-12-16 17:21:38 Re: logical changeset generation v6.8