| From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
|---|---|
| To: | pginfo <pginfo(at)t1(dot)unisoftbg(dot)com> |
| Cc: | Antonis Antoniou <a(dot)antoniou(at)albourne(dot)com>, "'pgsql-admin(at)postgresql(dot)org'" <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: vacuum full problem |
| Date: | 2003-11-11 15:09:37 |
| Message-ID: | 20031111070303.K60760@megazone.bigpanda.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Tue, 11 Nov 2003, pginfo wrote:
> Hi,
> I can not be sure if it is not the case.
> But we are usin this system on a number of servers and it happen only by
> one.
> Can I with a pg_locks help detect the query that is running?
It won't directly tell you what statement is running (although my guess is
also that it's probably something like an idle in transaction state
backend), but it can tell you if that's the problem probably.
You'd see something like:
...
21488 | 17057 | | 8613 | AccessShareLock | t
...
21488 | 17057 | | 8626 | AccessExclusiveLock | f
Which is basically saying that the command in pid 8626 is waiting on the
lock that pid 8613 has.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | pginfo | 2003-11-11 16:02:01 | Re: vacuum full problem |
| Previous Message | kbd | 2003-11-11 15:07:19 | Re: ER diagram tool for PostgresSQL7.3 |