Re: Safely Killing Backends (Was: Applications that leak connections) - Mailing list pgsql-general

From Jim Wilson
Subject Re: Safely Killing Backends (Was: Applications that leak connections)
Date
Msg-id 200502042201.j14M1htv021555@linus.kelco1.com
Whole thread Raw
In response to Safely Killing Backends (Was: Applications that leak connections)  (Thomas F.O'Connell <tfo@sitening.com>)
Responses Re: Safely Killing Backends (Was: Applications that leak connections)  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Re: Safely Killing Backends (Was: Applications that leak connections)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
> Jim Wilson <jimw@kelcomaine.com> writes:
> > If you are not very careful about how you handle orphaned
connections
> > in Postgres you will likely lose data....not "maybe" like a long
> > shot...but "likely".
>
> [ raised eyebrow ... ]  Say again?  I don\'t know of any reason why a
> lost connection would cause loss of (successfully committed)
transactions.
> Not even if a DBA with an itchy "kill -9" trigger finger is in charge
of
> cleaning up the lost connections.  Please describe the scenarios
you\'ve
> had problems with.
>
>             regards, tom lane
>

Well a couple things... One is I\\\'m talking about 7.3.x. We\\\'ll be
moving our servers up to 7.4.x before the spring, but that\\\'s where
these observations have been and maybe there are certain issues at that
level. It is sometimes difficult to track transaction related issues
down anyway, but I can say that in testing and earlier deployment we
saw some things that did not look good and in practice we are very
carefull dealing with lost connection issues. No kill -9 trigger
fingers.

Rather than getting into the raised eyebrow thing ;-), I\\\'d suggest
checking your "qualifiers". Consider that with Postgres, if killing a
single connection brings the whole server down, you will loose _all_
uncommitted data. If you did not, then I would call that a bug. The
weakness is not in the data integrity (directly), it is in the
integrity
of the server processes and their managability.

Best regards,

Jim



pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: plpgsql function errors
Next
From: Alvaro Herrera
Date:
Subject: Re: Safely Killing Backends (Was: Applications that leak connections)