Re: subtransaction assert failure - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: subtransaction assert failure
Date
Msg-id Pine.LNX.4.58.0409162206510.15621@linuxworld.com.au
Whole thread Raw
In response to Re: subtransaction assert failure  (Gavin Sherry <swm@linuxworld.com.au>)
List pgsql-hackers
On Thu, 16 Sep 2004, Gavin Sherry wrote:

> On Thu, 16 Sep 2004, Neil Conway wrote:
>
> > I can consistently repro this, provided I have the patience to run "make
> > check" enough times. Can anyone else repro the problem?
>
> I've managed to recreate this.
>
> I've tried on two linux 2.4 systems. One way and four way systems.
> Interestingly, I *cannot* recreate on the single CPU system and I cannot
> get abort() to generate a core. Neil has found the same problem under
> Linux.

Attached is a bt which does not appear to be corrupted:

#0  0x080adb70 in SubTransGetTopmostTransaction (xid=6384) at
subtrans.c:149
#1  0x08201984 in HeapTupleSatisfiesSnapshot (tuple=0x4074eba8,   snapshot=0x8388908) at tqual.c:798
#2  0x08083f17 in heapgettup (relation=0x40b17ba0, dir=1, tuple=0x83c09ec,   buffer=0x83c0a04, snapshot=0x8388908,
nkeys=0,key=0x0, pages=2)   at heapam.c:312
 
#3  0x08084db2 in heap_getnext (scan=0x83c09d8,
direction=ForwardScanDirection)   at heapam.c:830
#4  0x0812518a in SeqNext (node=0x0) at nodeSeqscan.c:102
#5  0x0811d664 in ExecScan (node=0x83c0594, accessMtd=0x8125110 <SeqNext>)   at execScan.c:98
#6  0x081251af in ExecSeqScan (node=0x83c0594) at nodeSeqscan.c:139
#7  0x0811904e in ExecProcNode (node=0x83c0594) at execProcnode.c:303
#8  0x08117a89 in ExecutePlan (estate=0x83bfd44, planstate=0x83c0594,   operation=CMD_UPDATE, numberTuples=0,
direction=137262828,
dest=0x82a1020)   at execMain.c:1060
#9  0x08116eeb in ExecutorRun (queryDesc=0x8388934,   direction=ForwardScanDirection, count=0) at execMain.c:226
#10 0x0812abbe in _SPI_pquery (queryDesc=0x8388934, tcount=0) at
spi.c:1498
#11 0x0812a978 in _SPI_execute_plan (plan=0x83d620c, Values=0x83840dc,   Nulls=0x838448c "  ~", '\177' <repeats 197
times>...,snapshot=0x0,   crosscheck_snapshot=0x0, read_only=0 '\0', tcount=0) at spi.c:1427
 
#12 0x081290b4 in SPI_execute_plan (plan=0x83d620c, Values=0x83840dc,   Nulls=0x838448c "  ~", '\177' <repeats 197
times>...,read_only=0
 
'\0',   tcount=0) at spi.c:309
#13 0x40b48d69 in exec_stmt_execsql (estate=0xbfffcee0, stmt=0x82e76ec)   at pl_exec.c:2155
#14 0x40b47782 in exec_stmt (estate=0xbfffcee0, stmt=0x838f988)   at pl_exec.c:1108
#15 0x40b47649 in exec_stmts (estate=0xbfffcee0, stmts=0x838fa20)   at pl_exec.c:1024
#16 0x40b47a9c in exec_stmt_if (estate=0xbfffcee0, stmt=0x835dbf0)   at pl_exec.c:1260
#17 0x40b476ea in exec_stmt (estate=0xbfffcee0, stmt=0x835dbf0)   at pl_exec.c:1068
#18 0x40b47649 in exec_stmts (estate=0xbfffcee0, stmts=0x835dc08)   at pl_exec.c:1024
#19 0x40b4751d in exec_stmt_block (estate=0xbfffcee0, block=0x835dcb8)   at pl_exec.c:979
#20 0x40b46c24 in plpgsql_exec_trigger (func=0x838fa90,
trigdata=0xbfffd0f0)   at pl_exec.c:655
#21 0x40b4368a in plpgsql_call_handler (fcinfo=0xbfffcfb0) at
pl_handler.c:124
#22 0x08104393 in ExecCallTriggerFunc (trigdata=0xbfffd0f0,
finfo=0x8338dd4,   per_tuple_context=0x832fc74) at trigger.c:1149
#23 0x08105368 in AfterTriggerExecute (event=0x83d133c, rel=0x1,   trigdesc=0x8338bc4, finfo=0x0,
per_tuple_context=0x832fc74)  at trigger.c:1964
 
#24 0x08105746 in afterTriggerInvokeEvents (events=0x83d12f0, firing_id=0,   delete_ok=1 '\001') at trigger.c:2160
#25 0x08105996 in AfterTriggerEndQuery () at trigger.c:2327
#26 0x0818a758 in ProcessQuery (parsetree=0x8338b78, plan=0x832e0f0,   params=0x0, dest=0xbfffd360,
completionTag=0xbfffd360"UPDATE 1")   at pquery.c:215
 
#27 0x0818b5bf in PortalRunMulti (portal=0x83369ac, dest=0x83adf08,   altdest=0x83adf08, completionTag=0xbfffd360
"UPDATE1") at
 
pquery.c:988
#28 0x0818aedf in PortalRun (portal=0x83369ac, count=2147483647,   dest=0x83adf08, altdest=0x83adf08,
completionTag=0xbfffd360"UPDATE
 
1")   at pquery.c:601
#29 0x0818794c in exec_simple_query (   query_string=0x832c4fc "update PField set name = 'PF0_2' where name =
'PF0_X';") at postgres.c:924
#30 0x08189c1f in PostgresMain (argc=4, argv=0x82e7a80,   username=0x82e791c "swm") at postgres.c:2967
#31 0x08161593 in BackendRun (port=0x82f6958) at postmaster.c:2848
#32 0x08161031 in BackendStartup (port=0x82f6958) at postmaster.c:2470
#33 0x0815f717 in ServerLoop () at postmaster.c:1215
#34 0x0815ec66 in PostmasterMain (argc=4, argv=0x82e74b0) at
postmaster.c:898
#35 0x081318eb in main (argc=4, argv=0x82e74b0) at main.c:265
#36 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6

The following may also be helpful:

(gdb) print RecentXmin
$2 = 6385

The xid passed to SubTransGetTopmostTransaction() is 6384.

Gavin



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: subtransaction assert failure
Next
From: Michael Glaesemann
Date:
Subject: Re: subtransaction assert failure