From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fwd: Core dump with nested CREATE TEMP TABLE |
Date: | 2015-09-04 04:02:11 |
Message-ID: | CAB7nPqQhf1wngZuh0Zdq9W0GWUzaDbCgA0VSEeiMQkZME8pLdA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 4, 2015 at 12:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
> > Hmm. I am not feeling especially comfortable about this: it's not clear
> > that there's anything preventing a suspended portal from containing a
> > dangerous reference. However, a quick trial did not show that it was
> > possible to break it --- in the cases I tried, we detected that a cached
> > plan was no longer valid, tried to rebuild it, and noticed the missing
> > object at that point. So maybe it's OK.
>
> After further thought I concluded that this probably is safe. The
> portal's original query was created and planned when it was opened,
> so it cannot contain any references to objects of the failed
> subtransaction. We have a hazard from queries within functions,
> but if the portal is suspended then no such functions are in progress.
>
> Attached is an updated patch with comments to this effect and some
> minor other code cleanup (mainly, not assuming that CurrentResourceOwner
> is the right thing to use in AtSubAbort_Portals).
>
Thanks! This looks good to me.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2015-09-04 04:05:48 | Re: BRIN INDEX value |
Previous Message | Tom Lane | 2015-09-04 03:51:29 | Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual) |