| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Race condition in HEAD, possibly due to PGPROC splitup |
| Date: | 2011-12-14 15:20:27 |
| Message-ID: | 6982.1323876027@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2011-12-14 15:21:29 | Re: foreign key locks, 2nd attempt |
| Previous Message | Tom Lane | 2011-12-14 15:16:59 | Re: Race condition in HEAD, possibly due to PGPROC splitup |