From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Frank Miles <fpm(at)u(dot)washington(dot)edu> |
Cc: | Michael Fuhr <mike(at)fuhr(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: What causes lock?? |
Date: | 2005-08-05 14:09:34 |
Message-ID: | 8365.1123250974@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Frank Miles <fpm(at)u(dot)washington(dot)edu> writes:
> ... By the way, in this forced condition, the rows that show granted='f'
> have blank relname, relation, and database fields :(
Those would be locks on transaction IDs, which is what you see in
pg_locks when someone is blocked on a row-level lock. (For reasons
of implementation efficiency, we don't record individual row locks
in a way that lets pg_locks see them :-()
This is definitely theorizing in advance of the evidence, but
I'm betting that your problem is due to locking of rows referenced
by foreign keys. Did you recently add some foreign key constraints
to your database?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bricklen Anderson | 2005-08-05 14:10:16 | Re: How to write jobs in postgresql |
Previous Message | Laura Vance | 2005-08-05 14:03:57 | Re: Going beyond sql |