Στις Τετάρτη 31 Οκτώβριος 2007 23:47, ο/η Scott Marlowe έγραψε:
> On 10/30/07, Achilleas Mantzios <achill@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > �����0 ��� 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.
Note nice surely, but why broken?
--
Achilleas Mantzios
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
