It might be helpful to look at pg_stat_activity.
...Robert
On Tue, Nov 11, 2008 at 10:08 PM, Philip Warner <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
>> Neither are we, because you left out all the columns that might tell
>> that ...
>>
>
> The columns are actually blankit's the other rows
Tom Lane wrote:
> Neither are we, because you left out all the columns that might tell
> that ...
>
The columns are actually blankit's the other rows I left out with
the row-level locks:
925282231 | 925280527 | | 62814 | RowExclusiveLock| t
925282208 | 925280527 |
Philip Warner <[EMAIL PROTECTED]> writes:
> Partial output of "select * from pg_locks":
>| | 1192675195 | 62860 | ShareLock | f
>| | 1192675195 | 62814 | ExclusiveLock | t
>| | 1192675195 | 62838 | ShareLock
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
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
