Στις Τρίτη 30 Οκτώβριος 2007 10:45, ο/η Patrick De Zlio έγραψε:
> Hi,
>
> We are running PostgreSQL 8.2.4 with quite highly updated millions rows
> tables.
>
> 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
apriori bad.
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
rollbacked.
>
> Thanks for help
--
Achilleas Mantzios
