Hot standby, race condition between recovery snapshot and commit

There's a race condition between transaction commit and
GetRunningTransactionData(). If GetRunningTransactionData() runs betweenthe 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