On Wed, Dec 14, 2011 at 3:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavan Deolasee <pavan.deolasee@gmail.com> writes:
>> Looking at CommitTransaction(), it seems quite clear to me that we
>> call ProcArrayEndTransaction() before releasing the locks held by the
>> transaction. So its quite possible that when
>> GetRunningTransactionLocks goes through the list of currently held
>> locks, the pgxact->xid is already cleared. This seems to a old bug to
>> me and not related to PGXACT work.
>
> Hm. So maybe the correct fix is to deem the lock already released
> if we get zero when we read the xid? It's not clear to me what the
> requirements for GetRunningTransactionLocks actually are, but if it's
> okay for it to think a lock is released slightly ahead of when the
> rest of the system thinks so, that would work.
Attached patch closes both race conditions:
* where xid is zero
* where xid is non-zero yet WAL record for the commit of xid wins race
ahead of the WAL record for locks
Patch fixes it in backwards compatible way.
No version increments.
Patch head, 9.1 and 9.0.
Will wait a couple of days for additional testing.
Comments?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services