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 20:43:37
Message-ID: 20131216204337.GL12902@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera wrote:

> 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.

After playing with this, I think the reason this seems to work without
fail is that all callers of HeapTupleSatisfiesUpdate are already
prepared to deal with the case where HeapTupleBeingUpdated is returned
but there is no actual transaction that would block the operation.
So I think the proposed patch is okay, barring a few more comments.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-12-16 20:51:17 Re: pgsql: Fix a couple of bugs in MultiXactId freezing
Previous Message Gregory Smith 2013-12-16 20:12:21 Re: row security roadmap proposal