On Thu, 2009-07-30 at 13:40 +0200, Craig Ringer wrote:
> > A simple ping to the client would have
> > cleared the fact that the client is not there anymore.
>
> Yep. It'd also stop PostgreSQL working for clients with software
> firewalls, since most of them drop ICMP ECHO ("ping").
I wasn't meaning TCP 'ping', but a higher level one...
> TCP keepalives are designed to do the same thing, but do it reliably and
> properly. Why not configure your tcp keepalive intervals instead?
Will do, normally we have good networking, never had to touch it before
(and have no experience in network problems anyway)...
> > the main thing
> > is: I would love to have this functionality. It's extremely hard to
> > secure all clients against crash, and a crash of one of the clients in
> > the middle of a transaction can have very bad consequences (think
> > indefinitely stucked open transaction).
>
> Nope. Just tune your keepalives if you have hopelessly flakey clients.
On the contrary, we do have very stable networking here, the problem was
never a networking one...
> Even if the client _program_ crashes, though, you shouldn't have
> anything left lying around. It's only if the client _OS_ crashes or the
> machine is hard-reset that you should be left with a backend lying
> around until tcp keepalives notice.
As explained in earlier email, the client box's OS went down in SWAP
hell.
Cheers,
Csaba.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
