Skip site navigation (1) Skip section navigation (2)

Re: BUG #5443: Undetected deadlock situation

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: (view raw, whole thread or download thread mbox)
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

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: Claudio FreireDate: 2010-04-30 16:07:48
Subject: Re: BUG #5443: Undetected deadlock situation
Previous:From: Robert HaasDate: 2010-04-30 14:03:52
Subject: Re: [9.0beta5/cvs head] build failure due to unchecked results

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group