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. | /
|/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
