| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Claudio" <claudio(at)livra(dot)com>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #5443: Undetected deadlock situation |
| Date: | 2010-04-30 15:50:47 |
| Message-ID: | 25790.1272642647@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Eliminating null columns and mangling column headers for length, I
> get this:
> locktype | tranid | virtualx | pid | mode | gr
> transactionid | 39773877 | 63/15761 | 11157 | ShareLock | f
> transactionid | 39773877 | 4/10902 | 6421 | ExclusiveLock | t
> So it looks like two locks on the same transaction ID by different
> transactions. How does that happen?
That's perfectly normal --- it indicates that pid 11157 is waiting for
a row-level lock that's currently held by pid 6421. We translate
row-level locking delays into waits for XID locks in order to limit
the number of distinct locks that have to be remembered in the shared
lock table. (We'd soon blow out shared memory if per-row lock data had
to be kept there.)
As Peter stated, there's no evidence of an actual problem in this
bug report. I'd go looking for clients sitting with open
transactions...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Claudio Freire | 2010-04-30 16:07:48 | Re: BUG #5443: Undetected deadlock situation |
| Previous Message | Robert Haas | 2010-04-30 14:03:52 | Re: [9.0beta5/cvs head] build failure due to unchecked results |