On Oct 4, 2006, at 5:59 AM, Tobias Brox wrote:
[Csaba Nagy - Thu at 10:45:35AM +0200]
So you should check for "idle in transaction" sessions, those are
bad...
or any other long running transaction.
Thank you (and others) for pointing this out, you certainly set us on
the right track. We did
[Csaba Nagy - Thu at 10:45:35AM +0200]
> So you should check for "idle in transaction" sessions, those are bad...
> or any other long running transaction.
Thank you (and others) for pointing this out, you certainly set us on
the right track. We did have some few unclosed transactions;
transaction
On Thu, Sep 28, 2006 at 08:56:31AM +0200, Tobias Brox wrote:
> CPU 0.00s/0.00u sec elapsed 0.00 sec.
> INFO: "my_queue": found 0 removable, 34058 nonremovable row versions in 185
> pages
^^^
You have a lot of dead rows that can't be removed. You must
On Thu, 2006-09-28 at 09:36, Tobias Brox wrote:
> [Tobias Brox - Thu at 08:56:31AM +0200]
> > It really seems like some transaction is still viewing the queue, since
> > it found 38k of non-removable rows ... but how do I find the pid of the
> > transaction viewing the queue? As said, the pg_locks
[Tobias Brox - Thu at 08:56:31AM +0200]
> It really seems like some transaction is still viewing the queue, since
> it found 38k of non-removable rows ... but how do I find the pid of the
> transaction viewing the queue? As said, the pg_locks didn't give me any
> hints ...
Dropping the table and
I have a query which really should be lightning fast (limit 1 from
index), but which isn't. I've checked the pg_locks table, there are no
locks on the table. The database is not under heavy load at the moment,
but the query seems to draw CPU power. I checked the pg_locks view, but
found nothing
