From: | Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: segfault of autovacuum process during restore - coredumps included |
Date: | 2005-11-29 00:00:29 |
Message-ID: | 200511290100.29959.ftm.van.vugt@foxi.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> Hm, I'm wondering if the toast-vs-index bug could be relevant. Could
> you try 8.1 branch tip? Or at least apply this patch:
>
> http://archives.postgresql.org/pgsql-committers/2005-11/msg00439.php
Hmm, the patch mentioned for ExecMain.c won't apply to my base version, so I
went for a fresh cvs checkout of REL8_1_STABLE instead. It took a while,
since Slack's version of Bison is too old and I needed to get a more recent
one.
Anyway, the restore still fails, backtrace against cvs now looks like this:
#0 0x0825382c in CopySnapshot (snapshot=0x0) at tqual.c:1301
1301 newsnap = (Snapshot) palloc(sizeof(SnapshotData) +
(gdb) where
#0 0x0825382c in CopySnapshot (snapshot=0x0) at tqual.c:1301
#1 0x081467db in fmgr_sql (fcinfo=0xbff21cb0) at functions.c:319
#2 0x0814017c in ExecMakeFunctionResult (fcache=0x84ce4a8,
econtext=0x84ce900, isNull=0xbff21f2b "$\033=\b", isDone=0x0) at
execQual.c:1095
#3 0x08142796 in ExecEvalExprSwitchContext (expression=0x84d04f4,
econtext=0x0, isNull=0xbff21f2b "$\033=\b", isDone=0x0) at execQual.c:2864
#4 0x08189f23 in evaluate_expr (expr=0x84ce4a8, result_type=23) at
clauses.c:2646
#5 0x0818b9b9 in simplify_function (funcid=291943, result_type=23,
args=0x84c60c0, allow_inline=1 '\001', context=0xbff22140) at clauses.c:2260
#6 0x0818beba in eval_const_expressions_mutator (node=0x84c5e44,
context=0xbff22140) at clauses.c:1305
#7 0x0818a68d in expression_tree_mutator (node=0x84c4688, mutator=0x818bce0
<eval_const_expressions_mutator>, context=0xbff22140) at clauses.c:3473
#8 0x0818bf1d in eval_const_expressions_mutator (node=0x84c477c,
context=0xbff22140) at clauses.c:1335
#9 0x0818c501 in eval_const_expressions_mutator (node=0x84c6004,
context=0xbff22140) at clauses.c:2030
#10 0x0818cb05 in eval_const_expressions (node=0x84c47a8) at clauses.c:1211
#11 0x0822ff93 in RelationGetIndexPredicate (relation=0x442fb9f4) at
relcache.c:2790
#12 0x080cb4cf in BuildIndexInfo (index=0x442fb9f4) at index.c:900
#13 0x080fec96 in analyze_rel (relid=293056, vacstmt=0x4422628c) at
analyze.c:257
#14 0x0813734b in vacuum (vacstmt=0x4422628c, relids=0x4421d89c) at
vacuum.c:476
#15 0x0819365f in autovacuum_do_vac_analyze (relids=0x44224154, dovacuum=0
'\0', doanalyze=1 '\001', freeze=0 '\0') at autovacuum.c:907
#16 0x0819401d in AutoVacMain (argc=0, argv=0x0) at autovacuum.c:681
#17 0x08194366 in autovac_start () at autovacuum.c:170
#18 0x0819a101 in ServerLoop () at postmaster.c:1269
#19 0x0819b292 in PostmasterMain (argc=3, argv=0x833b8a0) at postmaster.c:943
#20 0x0815bf3e in main (argc=3, argv=0x833b8a0) at main.c:256
Again and still, relation 293056 referred to in frame 13 is the
purchaseorder_line table.
--
Best,
Frank.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-11-29 00:10:37 | Re: segfault of autovacuum process during restore - coredumps included |
Previous Message | Tom Lane | 2005-11-28 22:46:29 | Re: segfault of autovacuum process during restore - coredumps included |