Re: vacuum full problem

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 17:36:50
Message-ID: 20031111093415.C65271@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Tue, 11 Nov 2003, pginfo wrote:

> The result by is:
> acc01=# select * from pg_locks;
> relation | database | transaction | pid | mode | granted
> ----------+----------+-------------+-------+-----------------+---------
> 16757 | 16976 | | 23169 | AccessShareLock | t
> 17062 | 16976 | | 1372 | AccessShareLock | t
> 17060 | 16976 | | 1372 | AccessShareLock | t
> | | 116303 | 1372 | ExclusiveLock | t
> | | 166846 | 23169 | ExclusiveLock | t
> 16995 | 16976 | | 1372 | AccessShareLock | t
> 17056 | 16976 | | 1372 | AccessShareLock | t
> 17038 | 16976 | | 1372 | AccessShareLock | t
> (8 rows)

Is that while the vacuum is running or just a general state that you might
run the vacuum in?

> And only transaction 116303 is the problem.
> Also it is production system with many transaction/sec and I am looking dor a
> way to detect what query is in this transaction ( if possible).
> The system is relativ big and it is dificult to detect this problem only from
> transacton number, but we will read the code to find the bug.

Well, you can turn on the statement statistics stuff and/or the
statement logging stuff to help you find what the various transactions
are doing. I'd wonder if you're maybe not closing a transaction after
it's completed its work though and so the locks are sitting around.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Stephan Szabo 2003-11-11 17:51:31 Re: vacuum full problem
Previous Message pginfo 2003-11-11 16:45:25 Re: vacuum full problem