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 22733.1451760367@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  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Thu, Sep 03, 2015 at 11:04:11PM -0400, Tom Lane wrote:
>> *************** AtSubAbort_Portals(SubTransactionId mySu

>> --- 909,966 ----
>> {
>> Portal        portal = hentry->portal;
>> 
>> +         /* Was it created in this subtransaction? */
>> if (portal->createSubid != mySubid)
>> +         {
>> +             /* No, but maybe it was used in this subtransaction? */
>> +             if (portal->activeSubid == mySubid)
>> +             {
> ...
>> +                 if (portal->status == PORTAL_ACTIVE)
>> +                     MarkPortalFailed(portal);

> Do you have a test case that reaches this particular MarkPortalFailed() call?
> My attempts stumbled over the fact that, before we reach here, each of the
> three MarkPortalActive() callers will have already called MarkPortalFailed()
> in its PG_CATCH block.  ("make check" does not reach this call.)

Offhand I think that's just belt-and-suspenders-too coding.  As you say,
we'd typically have failed active portals already before getting here.
But the responsibility of this routine is to *guarantee* that no broken
portals remain active, so I'd not want to remove this check.

Do you have a particular reason for asking?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Welcome to 2016, time to run src/tools/copyright.pl
Next
From: Tom Lane
Date:
Subject: Re: Some 9.5beta2 backend processes not terminating properly?