Re: segfault of autovacuum process during restore - coredumps included

> > I've changed autovacuum.c per this diff, I 'hope' I misinterpreted what
> > needed to be done (see below):
>
> No, that diff is exactly what I applied. But I think you must have done
> something else wrong

That's a bit harsh ;)

> , because while I can reproduce the crash easily on
> the unpatched tree with your example, it certainly does not crash on CVS
> HEAD.

Or HEAD contains something that either fixes or masks what's going on with my
v8.1 install........

FYI, it's a plain v8.1 with the given patch on autovacuum.c and an earlier
patch from Tom for the distinct bug which only touches ExecMain.c and
ExecUtils.c

> Test case attached for the curious ...

When I run that inside a transaction and wait for the autovacuum to kick in,
I'm not seeing any problem either.

Still, when restoring the larger dump, I immediately saw the same segfault. In
order to be sure I didn't forget it earlier, I did a make clean / make
install and tried again with the same result.

Given the original incidental nature of the problem combined with the fact
that I now get four coredumps out of four restores, I'd have to say the patch
is doing something alright ;).

The latest coredump refers to relid 284864 which again is the
purchaseorder_line table:

#0 0x0825361c in CopySnapshot (snapshot=0x0) at tqual.c:1301
1301 newsnap = (Snapshot) palloc(sizeof(SnapshotData) +
(gdb) bt
#0 0x0825361c in CopySnapshot (snapshot=0x0) at tqual.c:1301
#1 0x0814673b in fmgr_sql (fcinfo=0xbf9b2180) at functions.c:319
#2 0x081400bc in ExecMakeFunctionResult (fcache=0x847a598,
econtext=0x847a9f0, isNull=0xbf9b23fb "HrA\b", isDone=0x0) at execQual.c:1096
#3 0x081426d6 in ExecEvalExprSwitchContext (expression=0x847bcb4,
econtext=0x0, isNull=0xbf9b23fb "HrA\b", isDone=0x0) at execQual.c:2865
#4 0x08189e53 in evaluate_expr (expr=0x847a598, result_type=23) at
clauses.c:2646
#5 0x0818b8e9 in simplify_function (funcid=283751, result_type=23,
args=0x84685c0, allow_inline=1 '\001', context=0xbf9b2610) at clauses.c:2260
#6 0x0818bdea in eval_const_expressions_mutator (node=0x846a29c,
context=0xbf9b2610) at clauses.c:1305
#7 0x0818a5bd in expression_tree_mutator (node=0x8468be8, mutator=0x818bc10
<eval_const_expressions_mutator>, context=0xbf9b2610) at clauses.c:3473
#8 0x0818be4d in eval_const_expressions_mutator (node=0x846b128,
context=0xbf9b2610) at clauses.c:1335
#9 0x0818c431 in eval_const_expressions_mutator (node=0x84686f0,
context=0xbf9b2610) at clauses.c:2030
#10 0x0818ca35 in eval_const_expressions (node=0x8468c04) at clauses.c:1211
#11 0x0822fd83 in RelationGetIndexPredicate (relation=0x4423f4e8) at
relcache.c:2790
#12 0x080cb49f in BuildIndexInfo (index=0x4423f4e8) at index.c:900
#13 0x080febd6 in analyze_rel (relid=284864, vacstmt=0x44246058) at
analyze.c:257
#14 0x0813728b in vacuum (vacstmt=0x44246058, relids=0x44130d4c) at
vacuum.c:476
#15 0x0819350f in autovacuum_do_vac_analyze (relids=0x44245fd0, dovacuum=0
'\0', doanalyze=1 '\001', freeze=0 '\0') at autovacuum.c:906
#16 0x08193ecd in AutoVacMain (argc=0, argv=0x0) at autovacuum.c:680
#17 0x08194216 in autovac_start () at autovacuum.c:170
#18 0x08199fb1 in ServerLoop () at postmaster.c:1268
#19 0x0819b142 in PostmasterMain (argc=3, argv=0x833b8a0) at postmaster.c:943
#20 0x0815bece in main (argc=3, argv=0x833b8a0) at main.c:256

FYI, this table also has a non-standard deferred trigger defined on it:

(from '\d')
"RI_ConstraintTrigger_253215" AFTER INSERT OR DELETE OR UPDATE ON
purchaseorder_line DEFERRABLE INITIALLY DEFERRED FOR EACH ROW EXECUTE
PROCEDURE tr_purchaseorder_line_def()

Which is originally defined by:

CREATE OR REPLACE FUNCTION tr_purchaseorder_line_def()
RETURNS trigger
LANGUAGE 'plpgsql'
VOLATILE
STRICT
SECURITY INVOKER
AS ' DECLARE
BEGIN
<lots of code>
RETURN NULL;
END;';

CREATE CONSTRAINT TRIGGER purchaseorder_line_def AFTER INSERT OR UPDATE OR
DELETE ON purchaseorder_line DEFERRABLE INITIALLY DEFERRED FOR EACH ROW
EXECUTE PROCEDURE tr_purchaseorder_line_def();

--
Best,

Frank.