Re: Fwd: Core dump with nested CREATE TEMP TABLE

On Sun, Jan 31, 2016 at 11:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Noah Misch <noah(at)leadboat(dot)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."

+1. I think Noah's comment additions constitute useful and helpful
information, but I too am doubtful about the characterization of the
situations in question as bugs. I don't see what the evidence for
that is, especially given that it's quite hard to predict how the code
might change in the future. However, to reiterate, a more neutral
position of the same facts would get my vote.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company