>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
are commited 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 written the COMMIT WAL ?
Are there any chances of releasing locks which have no COMMIT WAL for releasing
them ?
regards,
--
Hiroyuki YAMADA
Kokolink Corporation
[email protected]
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
