Re: Hot Standby and prepared transactions

Hiroyuki Yamada wrote:
> By the way, reading LogStandbySnapshot() and GetRunningTransactionLocks()
> raised following questions.
> 
>  * There is a window beween gathering lock information in GetRunningTransactionLocks()
>    and writing WAL in LogAccessExclusiveLocks().
>  * In current lock redo algorithm, locks are released when the transaction holding the lock
>    are commited or aborted.
> 
> ... then what happens if any transaction holding ACCESS EXCLUSIVE lock commits in the 
>    window ?

Hmm, when replying the locks record, we should be ignoring entries
belonging to already-committed transactions. But I don't actually see
that in the code. That needs to be fixed, I think.

> Similary,
> 
>  * There is a window beween writing COMMIT WAL in RecordTransactionCommit() and
>     releasing locks in ResourceOwnerRelease()
> 
> ... then what happens when GetRunningTransactionLocks() gathers ACCESS EXCLUSIVE 
>    locks whose holder has already written the COMMIT WAL ?

This is handled in standby in the same manner as the above case.

> Are there any chances of releasing locks which have no COMMIT WAL for releasing them ?

Yes. In normal operation, there should eventually be a commit or abort
WAL record for every transaction. But as a safety valve, when a
running-xacts record is replayed, we mark as aborted all transactions
that are older than the oldest still-running XID according to the
running-xacts record, and release their locks. See StandbyReleaseOldLocks().

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