| From: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Brian Cox <brian(dot)cox(at)ca(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: "slow" queries |
| Date: | 2009-03-02 21:24:33 |
| Message-ID: | 20090302212433.GX8731@timac.local |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, Mar 02, 2009 at 02:29:31PM -0500, Tom Lane wrote:
> Brian Cox <brian(dot)cox(at)ca(dot)com> writes:
> > select locktype,database,relation,virtualxid,virtualtransaction,pid,mode
> > from pg_locks order by mode;
>
> If you hadn't left out the "granted" column we could be more sure,
> but what it looks like to me is the DROP (pid 13842) is stuck behind
> the <IDLE> transaction (pid 13833). In particular these two rows of
> pg_locks look like a possible conflict:
>
> > relation | 26472437 | 26472508 | | 15/69749
> > | 13842 | AccessExclusiveLock
>
> > relation | 26472437 | 26472508 | | 11/131
> > | 13833 | AccessShareLock
Would it be possible to write a stored procedure that would read
pg_locks, and other relevant tables, and list what's blocking what
in a simplified form?
Tim.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2009-03-02 21:59:47 | Re: "slow" queries |
| Previous Message | Brian Cox | 2009-03-02 20:36:33 | Re: "slow" queries |