Race condition in backend process exit

I can fairly consistently crash CVS tip with the following:

Session 1:

regression=# begin;
BEGIN
regression=# select * from int4_tbl where f1 = 123456 for update;  f1   
--------123456
(1 row)

Session 2:

regression=# begin;
BEGIN
regression=# select * from int4_tbl where f1 = 123456 for update;
<< blocks >>

Session 1:

regression=# \q

Session 2 now crashes:

TRAP: FailedAssertion("!(((xid) != ((TransactionId) 0)))", File: "lmgr.c", Line: 464)
LOG:  server process (PID 2337) was terminated by signal 6

with this backtrace:

#4  0x3000c4 in ExceptionalCondition (   conditionName=0xc4b3c "!(((xid) != ((TransactionId) 0)))",
errorType=0xc4a14"FailedAssertion", fileName=0xc49c8 "lmgr.c",    lineNumber=464) at assert.c:51
 
#5  0x265058 in XactLockTableWait (xid=0) at lmgr.c:464
#6  0x105730 in heap_lock_tuple (relation=0x7b03c451, tuple=0x7b03bdd0,    buffer=0x7b03bdec, cid=2063845554,
mode=LockTupleExclusive,nowait=0)   at heapam.c:2076
 
#7  0x1c5880 in ExecutePlan (estate=0x4010ab50, planstate=0xc0064b68,    operation=CMD_SELECT,
numberTuples=-1073329308,   direction=ForwardScanDirection, dest=0x40106708) at execMain.c:1192
 

Apparently, session 1's locks are being released while it still shows as
an active transaction in the PGPROC array, causing XactLockTableWait to
suppose it was a subtransaction and look for the parent.  This indicates
something is being done incompletely or in the wrong order during
backend exit, because AbortTransaction is perfectly clear that you mark
yourself not running before you release your locks.  Haven't found it
yet.

I could not provoke the same crash in 8.0, but I suspect this may just
be a chance timing difference, and that the bug may be of long standing.
        regards, tom lane