Re: auto_explain causes regression failures - Mailing list pgsql-hackers

Andrew Dunstan <andrew@dunslane.net> writes:
> I am getting regression failures on the rowtypes, transactions and 
> arrays tests. Diff file is attached. I'm going to look into it, but if 
> anyone has a good idea what's going on please speak up ASAP.

And as for the transactions-test failures, a stack trace tells the tale:

#0  errfinish (dummy=0) at elog.c:366
#1  0x00000000006e2d3c in elog_finish (elevel=<value optimized out>,    fmt=<value optimized out>) at elog.c:1145
#2  0x00000000006dbf9a in get_relid_attribute_name (relid=64726,    attnum=<value optimized out>) at lsyscache.c:786
#3  0x0000000000685d94 in get_variable (var=0x0, levelsup=45293976,    showstar=<value optimized out>,
context=0x7fffb0e11440)at ruleutils.c:3693
 
#4  0x000000000068a35d in deparse_expression_pretty (expr=0x2b320c0,    dpcontext=0x2a962e0, forceprefix=0 '\0',
showimplicit=127'\177',    prettyFlags=0, startIndent=<value optimized out>) at ruleutils.c:2055
 
#5  0x000000000052552c in show_plan_tlist (es=<value optimized out>,    plan=<value optimized out>) at explain.c:1286
#6  ExplainNode (es=<value optimized out>, plan=<value optimized out>)   at explain.c:1001
#7  0x00007f85f70341a3 in explain_ExecutorEnd (queryDesc=0x2abb918)   at auto_explain.c:244
#8  0x0000000000535684 in PortalCleanup (portal=<value optimized out>)   at portalcmds.c:268
#9  0x00000000006ff82f in AtSubAbort_Portals (mySubid=2,    parentSubid=<value optimized out>, parentXactOwner=<value
optimizedout>)   at portalmem.c:825
 
#10 0x000000000048a5ea in AbortSubTransaction () at xact.c:4016

We're trying to EXPLAIN a plan that refers to a table that no longer
exists, because the subtransaction that created it is already rolled
back.  I think the proximate fault here is in PortalCleanup, which
claims it ain't gonna do this:
   /*    * Shut down executor, if still running.  We skip this during error abort,    * since other mechanisms will
takecare of releasing executor resources,    * and we can't be sure that ExecutorEnd itself wouldn't fail.    */
 

but the test it's actually using is
       if (portal->status != PORTAL_FAILED)

and this particular portal is not marked FAILED, because it wasn't
running when the abort happened.  I think maybe we should force
portals into FAILED state when aborting a (sub)transaction.
Or leave the state alone but add a check on the transaction state
in this test in PortalCleanup.  Thoughts?

(Again, I think this is a pre-existing bug that auto_explain is just
exposing to the world ...)
        regards, tom lane