On Wed, 2009-12-16 at 19:35 +0900, Hiroyuki Yamada wrote: > * 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 ?
Yes, was a problem in that code. Fixed in git. We were doing it for prepared transactions but not for normal xacts. I will look again at that code. Thanks very much for reading the code. Any more?!? > 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 ? Same issue, so fixed as well. Thanks to Heikki for making that the same code path, so we have nothing to do for that. > Are there any chances of releasing locks which have no COMMIT WAL for > releasing them ? No -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
