Re: segfault of autovacuum process during restore - coredumps included - Mailing list pgsql-bugs
From | Frank van Vugt |
---|---|
Subject | Re: segfault of autovacuum process during restore - coredumps included |
Date | |
Msg-id | 200511282117.39997.ftm.van.vugt@foxi.nl Whole thread Raw |
In response to | Re: segfault of autovacuum process during restore - coredumps included (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: segfault of autovacuum process during restore - coredumps included
|
List | pgsql-bugs |
<TL> > No. There are two StartTransactionCommand calls in autovacuum.c, and > what I'm suggesting is to add the ActiveSnapshot assignment after each > one. <AH> > Done. I've changed autovacuum.c per this diff, I 'hope' I misinterpreted what needed to be done (see below): ====================================================== -- autovacuum.c_orig 2005-11-28 16:34:49.000000000 +0100 +++ autovacuum.c 2005-11-28 16:37:11.000000000 +0100 @@ -494,6 +494,9 @@ /* Start a transaction so our commands have one to play into. */ StartTransactionCommand(); + /* Begin a transaction for vacuuming this database */ + ActiveSnapshot = CopySnapshot(GetTransactionSnapshot()); + dbRel = heap_open(DatabaseRelationId, AccessShareLock); /* Must use a table scan, since there's no syscache for pg_database */ @@ -555,6 +558,9 @@ /* Start a transaction so our commands have one to play into. */ StartTransactionCommand(); + /* Begin a transaction for vacuuming this relation */ + ActiveSnapshot = CopySnapshot(GetTransactionSnapshot()); + /* * StartTransactionCommand and CommitTransactionCommand will automatically * switch to other contexts. We need this one to keep the list of ====================================================== Both the first and second attempt to restore my development database failed..... ;( Here's a new backtrace: #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=0xbfa79e20) at functions.c:319 #2 0x081400bc in ExecMakeFunctionResult (fcache=0x84e3780, econtext=0x84e3bd8, isNull=0xbfa7a09b "<\b", isDone=0x0) at execQual.c:1096 #3 0x081426d6 in ExecEvalExprSwitchContext (expression=0x850dfdc, econtext=0x0, isNull=0xbfa7a09b "<\b", isDone=0x0) at execQual.c:2865 #4 0x08189e53 in evaluate_expr (expr=0x84e3780, result_type=23) at clauses.c:2646 #5 0x0818b8e9 in simplify_function (funcid=267367, result_type=23, args=0x84ed6d0, allow_inline=1 '\001', context=0xbfa7a2b0) at clauses.c:2260 #6 0x0818bdea in eval_const_expressions_mutator (node=0x84ed454, context=0xbfa7a2b0) at clauses.c:1305 #7 0x0818a5bd in expression_tree_mutator (node=0x84e35a0, mutator=0x818bc10 <eval_const_expressions_mutator>, context=0xbfa7a2b0) at clauses.c:3473 #8 0x0818be4d in eval_const_expressions_mutator (node=0x84e3694, context=0xbfa7a2b0) at clauses.c:1335 #9 0x0818c431 in eval_const_expressions_mutator (node=0x84ed614, context=0xbfa7a2b0) at clauses.c:2030 #10 0x0818ca35 in eval_const_expressions (node=0x84e36c0) at clauses.c:1211 #11 0x0822fd83 in RelationGetIndexPredicate (relation=0x4433f40c) at relcache.c:2790 #12 0x080cb49f in BuildIndexInfo (index=0x4433f40c) at index.c:900 #13 0x080febd6 in analyze_rel (relid=268480, vacstmt=0x4422f4a0) at analyze.c:257 #14 0x0813728b in vacuum (vacstmt=0x4422f4a0, relids=0x44228dcc) at vacuum.c:476 #15 0x0819350f in autovacuum_do_vac_analyze (relids=0x4422e528, 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 -- Best, Frank.
pgsql-bugs by date: