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

<div dir="ltr"><br /><br />On Wed, Sep 2, 2015 at 6:13 AM, Jim Nasby <<a
href="mailto:Jim.Nasby@bluetreble.com">Jim.Nasby@bluetreble.com</a>>wrote:<br />> On 9/1/15 11:59 PM, Michael
Paquierwrote:<br />>><br />>> On Wed, Sep 2, 2015 at 12:59 PM, Jim Nasby wrote:<br />>>><br
/>>>>On 9/1/15 8:42 PM, Michael Paquier wrote:<br />>>> The crash is triggered by having an exception
raisedin this particular<br />>>> call<br />>>> stack. Since there's no syntax error in master/0.2.1,
there'sno assert<br />>>> failure either. Were you running asserts?<br />>><br />>><br />>>
Ithought I was, but visibly it was mistaken. So, after re-rolling<br />>> configure, I have been able to
reproducethe crash, and as far as I<br />>> can see all supported versions are impacted. I tested down to 9.1<br
/>>>where extensions were introduced, and the stack trace, as well as the<br />>> assertion failing are the
same,similar to what Jim has reported. I am<br />>> just digging more into this thing now.<br />><br />><br
/>>I just had a theory that reference counts were messed up because there was<br />> both a temp table and a real
tablewith the same name. Turns out that's not<br />> the case, but I do now know that the assert is failing for the
reference<br/>> count on the temp table.<br /><br />Yes, that's what I have been looking at actually by having some
markersin relcache.c. The reference count of this relation get incremented here:<br />LOG:  increment ref count
relation:invoice_0000000003, rd_refcnt: 1<br />CONTEXT:  SQL statement "<br />        CREATE TEMP TABLE
invoice_0000000003ON COMMIT DROP AS<br />        WITH i AS (<br />              INSERT INTO invoice VALUES(<br />     
             DEFAULT<br />                    , (tf.get( NULL::customer, 'insert' )).customer_id<br />                 
 , current_date<br />                    , current_date + 30<br />                  ) RETURNING *<br />            )<br
/>         SELECT *<br />            FROM i<br />        "<br />        PL/pgSQL function tf.get(anyelement,text) line
29at EXECUTE<br />        PL/pgSQL function results_eq(refcursor,refcursor,text) line 11 at FETCH<br />        PL/pgSQL
functionresults_eq(text,text,text) line 9 at assignment<br />STATEMENT:  SELECT results_eq(<br />          $$SELECT *
FROMtf.get( NULL::invoice, 'base' )$$<br />          , $$VALUES( 1, 1, current_date, current_date + 30 )$$<br />       
 , 'invoice factory output'<br />        );<br />And it gets cleared here without being decremented when cleaning up
thesecond exception:<br />LOG:  clear relation: invoice_0000000003, rd_refcnt: 1<br />CONTEXT:  PL/pgSQL function
results_eq(refcursor,refcursor,text)line 11 during exception cleanup<br />        PL/pgSQL function
results_eq(text,text,text)line 9 at assignment<br />STATEMENT:  SELECT results_eq(<br />          $$SELECT * FROM
tf.get(NULL::invoice, 'base' )$$<br />          , $$VALUES( 1, 1, current_date, current_date + 30 )$$<br />          ,
'invoicefactory output'<br />        );<br />-- <br />Michael</div>