Re: auto_explain causes regression failures

Andrew Dunstan <andrew(at)dunslane(dot)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 optimized out>)
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 take care 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