Re: Fwd: Core dump with nested CREATE TEMP TABLE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fwd: Core dump with nested CREATE TEMP TABLE
Date
Msg-id 67674.1454259004@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fwd: Core dump with nested CREATE TEMP TABLE  (Noah Misch <noah@leadboat.com>)
Responses Re: Fwd: Core dump with nested CREATE TEMP TABLE  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Sat, Jan 30, 2016 at 04:28:47PM -0500, Robert Haas wrote:
>> I think I've
>> pretty much said what I have to say about this; if nothing I wrote up
>> until now swayed you, it's unlikely that anything else I say after
>> this point will either.

> Say I drop the parts that change the binary.  Does the attached v2 manage to
> improve PostgreSQL, or is it neutral-or-harmful like v1?

There can surely be no objection to improving these comments.  However,
I'm not convinced that we should word the comments to insist that the
hypothetical cases are bugs.  As I said before, I do not think there is an
API contract that would promise that portals don't reach here in ACTIVE
state.  So IMO it's fair to note that no such case can arise currently,
but not to state that it's a bug if it does.  So for example I'd reword
your last comment addition along the lines of "Currently, every
MarkPortalActive() caller ensures it updates the portal status again
before relinquishing control, so that ACTIVE can't happen here.  If it
does happen, dispose the portal like existing MarkPortalActive() callers
would."
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal: Trigonometric functions in degrees
Next
From: Fabien COELHO
Date:
Subject: Re: extend pgbench expressions with functions