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

Re: [ADMIN] how to find transaction associated with a lock

From: Si Chen <schen(at)graciousstyle(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [ADMIN] how to find transaction associated with a lock
Date: 2004-07-22 21:44:29
Message-ID: 4100353D.9080202@graciousstyle.com (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-generalpgsql-novice
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(at)graciousstyle(dot)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
>
>  
>


In response to

Responses

pgsql-novice by date

Next:From: Tom LaneDate: 2004-07-22 22:37:21
Subject: Re: [ADMIN] how to find transaction associated with a lock
Previous:From: Tom LaneDate: 2004-07-22 20:45:03
Subject: Re: how to find transaction associated with a lock

pgsql-admin by date

Next:From: Ian BurrellDate: 2004-07-22 22:10:41
Subject: Re: Invalid page header
Previous:From: Tom LaneDate: 2004-07-22 20:45:03
Subject: Re: how to find transaction associated with a lock

pgsql-general by date

Next:From: culley harrelsonDate: 2004-07-22 21:58:05
Subject: any benefit to preparing a sql function?
Previous:From: Tom LaneDate: 2004-07-22 20:45:03
Subject: Re: how to find transaction associated with a lock

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