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: