Re: How to kill process "idle in transaction"
От | Scott Marlowe |
---|---|
Тема | Re: How to kill process "idle in transaction" |
Дата | |
Msg-id | dcc563d10710311447t2a2519f7n59d3e2a1c06b6f79@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: How to kill process "idle in transaction" (Achilleas Mantzios <achill@matrix.gatewaynet.com>) |
Ответы |
Re: How to kill process "idle in transaction"
Re: How to kill process "idle in transaction" |
Список | pgsql-admin |
On 10/30/07, Achilleas Mantzios <achill@matrix.gatewaynet.com> wrote: > Στις Τρίτη 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. You can turn off that behaviour, IIRC. It is broken behaviour as far as pgsql is concerned, I believe.
В списке pgsql-admin по дате отправления: