Re: Race condition in HEAD, possibly due to PGPROC splitup - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Race condition in HEAD, possibly due to PGPROC splitup
Date
Msg-id 6982.1323876027@sss.pgh.pa.us
Whole thread Raw
In response to Re: Race condition in HEAD, possibly due to PGPROC splitup  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Responses Re: Race condition in HEAD, possibly due to PGPROC splitup  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Race condition in HEAD, possibly due to PGPROC splitup  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Race condition in HEAD, possibly due to PGPROC splitup
Next
From: Noah Misch
Date:
Subject: Re: foreign key locks, 2nd attempt