Re: subtransaction assert failure - Mailing list pgsql-hackers

I am also seeing regular "make check" failures on my test buildfarm 
system (FC1, 2.4.22 kernel, cassert turned on):
sysname |      snapshot       | status | stage--------+---------------------+--------+-------cat     | 2004-09-15
15:25:59|      2 | Checkcat     | 2004-09-15 23:27:37 |      0 | OKcat     | 2004-09-16 00:25:55 |      2 | Check
 

cheers

andrew


Neil Conway wrote:

> I'm seeing an intermittent assertion failure while running "make 
> check" with current sources. I can usually reproduce the problem at 
> least once out of every 3 or 4 runs of "make check" on each of two 
> different machines (one is an 866 mhz iBook running OSX, the other is 
> a dual Xeon @ 2.8 ghz running Debian w/ kernel 2.6). The assertion 
> failure is:
>
> TRAP: FailedAssertion("!(TransactionIdFollowsOrEquals(xid, 
> RecentXmin))", File: 
> "/Users/neilc/pgsql/src/backend/access/transam/subtrans.c", Line: 146)
>
> The backtrace is:
>
> #0  0x900429ac in kill ()
> #1  0x9009eb1c in abort ()
> #2  0x001c3b60 in ExceptionalCondition (conditionName=0x0, 
> errorType=0x25 "", fileName=0x95 "", lineNumber=1768842554) at 
> /Users/neilc/pgsql/src/backend/utils/error/assert.c:51
> #3  0x000461c8 in SubTransGetTopmostTransaction (xid=6145) at 
> /Users/neilc/pgsql/src/backend/access/transam/subtrans.c:146
> #4  0x001e266c in HeapTupleSatisfiesSnapshot (tuple=0x1801, 
> snapshot=0x1801) at /Users/neilc/pgsql/src/backend/utils/time/tqual.c:798
> #5  0x00016330 in heap_release_fetch (relation=0xae2a40, 
> snapshot=0x203ec1c, tuple=0x2048f6c, userbuf=0x2048f84, keep_buf=1 
> '\001', pgstat_info=0x2048fa8) at 
> /Users/neilc/pgsql/src/backend/access/heap/heapam.c:973
> #6  0x0001efa4 in index_getnext (scan=0x1, direction=11414080) at 
> /Users/neilc/pgsql/src/backend/access/index/indexam.c:524
> #7  0x000cd420 in IndexNext (node=0x27615c) at 
> /Users/neilc/pgsql/src/backend/executor/nodeIndexscan.c:316
> #8  0x000c6f5c in ExecScan (node=0x20489d8, accessMtd=0xcd114 
> <IndexNext>) at /Users/neilc/pgsql/src/backend/executor/execScan.c:98
> #9  0x000c1c4c in ExecProcNode (node=0x20489d8) at 
> /Users/neilc/pgsql/src/backend/executor/execProcnode.c:307
> #10 0x000ceac8 in ExecMergeJoin (node=0x20489d8) at 
> /Users/neilc/pgsql/src/backend/executor/nodeMergejoin.c:754
> #11 0x000c1c88 in ExecProcNode (node=0x2048680) at 
> /Users/neilc/pgsql/src/backend/executor/execProcnode.c:330
> #12 0x000cabe8 in agg_retrieve_direct (aggstate=0x2048388) at 
> /Users/neilc/pgsql/src/backend/executor/nodeAgg.c:762
> #13 0x000c1cc4 in ExecProcNode (node=0x2048388) at 
> /Users/neilc/pgsql/src/backend/executor/execProcnode.c:353
> #14 0x000d0b84 in ExecSort (node=0x20482fc) at 
> /Users/neilc/pgsql/src/backend/executor/nodeSort.c:102
> #15 0x000c1cac in ExecProcNode (node=0x20482fc) at 
> /Users/neilc/pgsql/src/backend/executor/execProcnode.c:345
> #16 0x000c0294 in ExecutePlan (estate=0x204801c, planstate=0x20482fc, 
> operation=CMD_SELECT, numberTuples=0, direction=1768842554, 
> dest=0xaf2684) at /Users/neilc/pgsql/src/backend/executor/execMain.c:1060
> #17 0x000bf4ac in ExecutorRun (queryDesc=0x203ec48, 
> direction=33849372, count=0) at 
> /Users/neilc/pgsql/src/backend/executor/execMain.c:226
> #18 0x001521f8 in PortalRunSelect (portal=0x201f5c8, forward=-4 '?', 
> count=33811528, dest=0x0) at 
> /Users/neilc/pgsql/src/backend/tcop/pquery.c:718
> [...]
>
> (captured from the OSX machine; note that certain parts of the 
> backtrace seem corrupted, so I wouldn't put _too_ much faith in it.)
>
> I can consistently repro this, provided I have the patience to run 
> "make check" enough times. Can anyone else repro the problem?
>
> -Neil
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>