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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
