subtransaction assert failure - Mailing list pgsql-hackers

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