Sorry, should RTFM more closely:

"If a transaction is waiting for a row-level lock, it will usually
appear in the view as waiting for the transaction ID
of the current holder of that row lock."

so I need to look at the row locks on the blocker.


Philip Warner wrote:
Hi,

Can anyone explain the way to debug this kind of situation and/or
explain the meaning of these locks?

Partial output of "select * from pg_locks":
1192675195 | 62860 | ShareLock | f
1192675195 | 62814 | ExclusiveLock | t
1192675195 | 62838 | ShareLock | f
1192675195 | 63525 | ShareLock | f
where 1192675195 is the 'transaction' field.

I am not at all clear what the processes are waiting for, or if there is
a way to reduce such contention.

--
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 03 5330 3171 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
http://www.rhyme.com.au <http://www.rhyme.com.au/>
/ \|
--________--
GPG key available upon request. | /
/

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 5 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedNov 12, '08 at 2:38a
activeNov 12, '08 at 4:37a
posts5
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase