Re: Exclusive Locks Taken on User Tables? - Mailing list pgsql-general

From Marc
Subject Re: Exclusive Locks Taken on User Tables?
Date
Msg-id 809128960711061253l76b92e3cn2d703b0e2595a7de@mail.gmail.com
Whole thread Raw
In response to Re: Exclusive Locks Taken on User Tables?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Exclusive Locks Taken on User Tables?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Exclusive Locks Taken on User Tables?  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-general
Ok.  I'll keep looking at pg_locks. 

My original reason for reaching out to the list was over confusion as to when an EXCLUSIVE lock would be taken table level since the documentation says this should never happen except to some system catalogs.  Is there something missing from the documentation?  I feel like that would be a big clue.  Here is what I'm referencing: http://www.postgresql.org/docs/8.2/interactive/explicit-locking.html

Thanks for your help!
---Marc

On Nov 6, 2007 3:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
 
Well, if it's not a foreign key issue then I think that the UPDATE is
blocked waiting for some previous updater of the same row to commit.
If you poke around a bit harder in pg_locks you'll probably find that
the UPDATE is waiting to acquire ShareLock on someone else's transaction
ID, and that someone else is the culprit.

                       regards, tom lane

pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Npsql is much faster than ODBC ?
Next
From: Tom Lane
Date:
Subject: Re: Exclusive Locks Taken on User Tables?