Re: Hot Standby and prepared transactions

>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
yamada(at)kokolink(dot)net