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-18 08:27:40
Message-ID: 20131218082740.GB5224@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2013-12-17 18:27:26 -0300, Alvaro Herrera wrote:
> > Well, it would help if those cases weren't dead code. Neither
> > heap_update nor heap_delete are ever called in the "no wait" case at
> > all.

Yea, that sucks, maybe we ought to change that in HEAD. But there very
well might be external callers that use it, I don't think we can just
break the API in a stable release.

> > Only heap_lock_tuple is, and I can't see any misbehavior there
> > either, even with HeapTupleBeingUpdated returned when there's a
> > non-local locker, or when there's a MultiXact as xmax, regardless of its
> > status.
>
> I spent some more time trying to generate a test case that would show a
> problem with the changed return values here, and was unable to.
>
> I intend to apply this patch soon.

I have to say, it makes me really uncomfortable to take such
shortcuts. In other branches we are doing liveliness checks with
MultiXactIdIsRunning() et al. Why isn't that necessary here? And how
likely is that this won't cause breakage somewhere down the line because
somebody doesn't know of that subtlety?

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 Craig Ringer 2013-12-18 08:30:13 Re: row security roadmap proposal
Previous Message Pavel Stehule 2013-12-18 08:09:54 Re: patch: make_timestamp function