Στις Τρίτη 30 Οκτώβριος 2007 10:45, ο/η Patrick De Zlio έγραψε:
> We are running PostgreSQL 8.2.4 with quite highly updated millions rows
> It comes sometimes to get some "idle in transaction" processes, which
> doesn't have first really viewable effect out of giving very bad estimated
> numbers for pgclass.reltuples and, if we let them run as it is, block the
> autovacuum from releasing rows, and after few days some worse problems.
> Now we are able to detect these "idle in transaction" processes, but what
> to do with them ?
> What to do to avoid such situation? How to find the bad request which put
> the process in this state? From the time it is idle in transaction, we
> can't see the query in the pg_lock table anymore.
> How to deal with such process when it is already idle in transaction? can
> we simply kill it? It is a backend from pgpool. Can we simply restart it
> (how) without restarting all the database?
Some connection pools issue a BEGIN on the connection just
after the previous user of the connection issues COMMIT and
then closes it (Jboss does it). So, <IDLE> in transaction is not
However if in your system you have lock problems,
and transactions that dont get rollbacked or commited,
then it is a problem with your application.
Have you done any monitoring on the size of the pool?
You should look at:
1) Connections get closed eventually
2) Transactions either have the autocommit flag on, are commited or are
> Thanks for help
In response to
pgsql-admin by date
|Next:||From: H. Hall||Date: 2007-10-30 10:01:32|
|Subject: [Fwd: Indexes for Foreign Keys?]|
|Previous:||From: Patrick De Zlio||Date: 2007-10-30 08:45:16|
|Subject: How to kill process "idle in transaction"|