From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Hiroyuki Yamada <yamada(at)kokolink(dot)net> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Hot Standby and prepared transactions |
Date: | 2009-12-16 13:15:21 |
Message-ID: | 1260969321.634.1299.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | tomas | 2009-12-16 13:23:40 | Re: Range types |
Previous Message | Simon Riggs | 2009-12-16 12:55:33 | Re: Hot Standby and prepared transactions |