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