>On Wed, 2009-12-16 at 18:08 +0900, Hiroyuki Yamada wrote:
>> >That fixes or explains all known issues, from me. Are there any other
>> >things you know about that I haven't responded to? Do you think we have
>> >addressed every issue, except deferred items?
>> >
>> >I will be looking to commit to CVS later today; waiting on any
>> >objections.
>> >
>>
>> Is following problem reported or fixed ?
>
>That is fixed, as of a couple of days ago. Thanks for your vigilence.
>
I tested somewhat older patch(the RC patch in this mailing list). Sorry for annoying you.
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
arecommited or aborted.
... then what happens if any transaction holding ACCESS EXCLUSIVE lock commits in the window ?
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
writtenthe COMMIT WAL ?
Are there any chances of releasing locks which have no COMMIT WAL for releasing them ?
regards,
-- Hiroyuki YAMADA Kokolink Corporation yamada@kokolink.net
