Re: Fwd: Core dump with nested CREATE TEMP TABLE
От | Michael Paquier |
---|---|
Тема | Re: Fwd: Core dump with nested CREATE TEMP TABLE |
Дата | |
Msg-id | CAB7nPqQhf1wngZuh0Zdq9W0GWUzaDbCgA0VSEeiMQkZME8pLdA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fwd: Core dump with nested CREATE TEMP TABLE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Fwd: Core dump with nested CREATE TEMP TABLE
|
Список | pgsql-hackers |
<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Fri, Sep 4, 2015 at 12:04 PM, Tom Lane <spandir="ltr"><<a href="mailto:tgl@sss.pgh.pa.us" target="_blank">tgl@sss.pgh.pa.us</a>></span> wrote:<br /><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">I wrote:<br/> > Hmm. I am not feeling especially comfortable about this: it's not clear<br /> > that there's anythingpreventing a suspended portal from containing a<br /> > dangerous reference. However, a quick trial did not showthat it was<br /> > possible to break it --- in the cases I tried, we detected that a cached<br /> > plan was nolonger valid, tried to rebuild it, and noticed the missing<br /> > object at that point. So maybe it's OK.<br /><br/></span>After further thought I concluded that this probably is safe. The<br /> portal's original query was createdand planned when it was opened,<br /> so it cannot contain any references to objects of the failed<br /> subtransaction. We have a hazard from queries within functions,<br /> but if the portal is suspended then no such functionsare in progress.<br /><br /> Attached is an updated patch with comments to this effect and some<br /> minor othercode cleanup (mainly, not assuming that CurrentResourceOwner<br /> is the right thing to use in AtSubAbort_Portals).<br/></blockquote></div><br /></div><div class="gmail_extra">Thanks! This looks good to me.<br />-- <br/><div class="gmail_signature">Michael<br /></div></div></div>
В списке pgsql-hackers по дате отправления: