Re: Race condition in HEAD, possibly due to PGPROC splitup
| От | Simon Riggs |
|---|---|
| Тема | Re: Race condition in HEAD, possibly due to PGPROC splitup |
| Дата | |
| Msg-id | CA+U5nMKbFeGGLWPwuXr2RcKKgsRZBbStZ6wpqMdfhiAQiYw-=A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Race condition in HEAD, possibly due to PGPROC splitup (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
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. OK, I'll look at this. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: