Hi Tom,
Thanks for the reply. I looked in pg_stat_activity and it shows
database tables and process ids. So I should be using the pid next to
the ExclusiveLock to see what database it is working on, right?
Now, the problem that I had was this: I have a java application that
access postgresql (7.3.2) via jdbc. It was running fine for a while,
then of all sudden, against one table, the INSERT would simply hang. It
would INSERT fine on many other tables and the application could still
run, except for INSERTs involving this particular table (unfortunately,
an important table.)
Someone else had suggested that it was perhaps a lock on that particular
table. So I looked up view locking and then thought that this was where
the bug was occurring. Do you think I'm looking down the wrong path?
Might it be something else (like the lack of a recent vacuuming or fsync
not being set to true in postgresql.conf) that was causing this bug?
Thanks so much for your help!
Si Chen
Tom Lane wrote:
>Si Chen <schen@graciousstyle.com> writes:
>
>
>>Does anyone know of a way to go from transactions identifiers to the
>>actual transaction--which tables, which statements, etc. etc.?
>>
>>
>
>See pg_stat_activity.
>
>The pg_locks entries you are looking at do *not* represent table locks
>of any kind. This:
>
>
>>NULL NULL 3366868 27149 ExclusiveLock TRUE
>>
>>
>simply says that transaction 3366868 is still running. This:
>
>
>>NULL NULL 3366868 1069 ShareLock FALSE
>>
>>
>says that process 1069 has elected to wait until transaction 3366868
>finishes. Normally the reason for doing that would be that transaction
>3366868 holds a row lock (SELECT FOR UPDATE lock) on some row that
>process 1069's transaction wants to acquire row lock on.
>
>However, I suspect what you are really wishing is to find out the
>individual row that is being contended for, and there is not enough
>information in the system views to do that (mainly because we do not
>keep per-row locking information in shared memory).
>
> regards, tom lane
>
>
>
