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