Re: 9.3 reference constraint regression

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Daniel Wood <dwood(at)salesforce(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 9.3 reference constraint regression
Date: 2013-12-16 20:57:28
Message-ID: 20131216205728.GF6019@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-12-16 17:43:37 -0300, Alvaro Herrera wrote:
> 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.

Are you sure? the various wait/nowait cases don't seem to handle that
correctly.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-12-16 21:49:22 Re: planner missing a trick for foreign tables w/OR conditions
Previous Message Alvaro Herrera 2013-12-16 20:51:17 Re: pgsql: Fix a couple of bugs in MultiXactId freezing