Re: subtransaction assert failure

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 | Check
cat | 2004-09-15 23:27:37 | 0 | OK
cat | 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
>