Hot standby, race condition between recovery snapshot and commit

There's a race condition between transaction commit and
GetRunningTransactionData(). If GetRunningTransactionData() runs between
 the RecordTransactionCommit() and ProcArrayEndTransaction() calls in
CommitTransaction():

> 	/*
> 	 * Here is where we really truly commit.
> 	 */
> 	latestXid = RecordTransactionCommit(false);
> 
> 	TRACE_POSTGRESQL_TRANSACTION_COMMIT(MyProc->lxid);
> 
> 	/*
> 	 * Let others know about no transaction in progress by me. Note that this
> 	 * must be done _before_ releasing locks we hold and _after_
> 	 * RecordTransactionCommit.
> 	 */
> 	ProcArrayEndTransaction(MyProc, latestXid);

The running-xacts snapshot will include the transaction that's just
committing, but the commit record will be before the running-xacts WAL
record. If standby initializes transaction tracking from that
running-xacts record, it will consider the just-committed transactions
as still in-progress until the next running-xact record (at next
checkpoint).

I can't see any obvious way around that. We could have transaction
commit acquire the new RecoveryInfoLock across those two calls, but I'd
like to avoid putting any extra overhead into such a critical path.

Hmm, actually ProcArrayApplyRecoveryInfo() could check every xid in the
running-xacts record against clog. If it's marked as finished in clog
already (because we already saw the commit/abort record before the
running-xacts record), we know it's not running after all.

Because of the sequence that commit removes entry from procarray and
releases locks, it also seems possible for GetRunningTransactionsData()
to acquire a snapshot that contains an AccessExclusiveLock for a
transaction, but that XID is not listed as running in the XID list. That
sounds like trouble too.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com