From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | wiki on monitoring locks has queries that don't seem to work |
Date: | 2013-11-25 19:57:18 |
Message-ID: | CAOR=d=2i3dnNgaNyej5aU1JjGZCcMjPQTMa5LtZWKQoz+cnM2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
So I'm running 8.4 and go to this
page:http://wiki.postgresql.org/wiki/Lock_Monitoring
I have a query that is definitely blocked by another query. I run the
first or third queries, the ones that explicitly say that they're for
<9.2 and neither produces any output. The third query gives me a list
of 182 rows, only a few of which are actually locked in any meaningful
ways.
Now if I run this query:
select relname,pg_locks.* from pg_class,pg_locks where
relfilenode=relation and not granted;
I get the one row for the update / insert / delete that is getting blocked.
I could swear that the original query:
select bl.pid as blocked_pid, a.usename as blocked_user,
kl.pid as blocking_pid, ka.usename as blocking_user,
a.current_query as blocked_statement
from pg_catalog.pg_locks bl
join pg_catalog.pg_stat_activity a
on bl.pid = a.procpid
join pg_catalog.pg_locks kl
join pg_catalog.pg_stat_activity ka
on kl.pid = ka.procpid
on bl.transactionid = kl.transactionid and bl.pid != kl.pid
where not bl.granted;
worked once upon a time, but no longer. If anyone has a newer query
that works on <9.2 they could pass along that would be great.
--
To understand recursion, one must first understand recursion.
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2013-11-25 20:35:40 | Re: passing tables name into a cursor |
Previous Message | Janek Sendrowski | 2013-11-25 19:31:13 | Debugging of C functions |