Re: Feature freeze date for 8.1

From: Alvar Freude <alvar(at)a-blast(dot)org>
To: adnandursun(at)asrinbilisim(dot)com(dot)tr, pgsql-hackers(at)postgresql(dot)org
Cc: Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Feature freeze date for 8.1
Date: 2005-05-02 20:56:31
Message-ID: E2CCD1B8D0E4DED059FB5FC6@Chefkoch.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

-- adnandursun(at)asrinbilisim(dot)com(dot)tr wrote:

> So this means, If client does never try to send data the
> resources would be going to be held.
> I think it is not a good solution to find zombie / dead
> connection and clear them..

With TCP/IP you DON'T have any other options then waiting for a timeout. In
one or another way. This is a feature of TCP connections.

But when happens this?

A) when you unplug the client or server from the net without shutdown
B) when you firewall the client or server ("deny all from any to any")

When one of this happens, there is another serious problem. First you should
handle this.

AFAIK is A) managable by switches our routers.

With SO_KEEPALIVE there is a chance to detect dead connections earlyer: when
sending or receiving data. Perhaps it is possible to write a daemon, which
surveys all open sockets of a machine and kills the owner of any dead socket.
But this something for the OS, not for PostgreSQL.

Another option is to check periodical with select (2) the connections
(instead of sending/receiving something); I'm not a TCP/IP specialist, but
perhaps this helps in these rare situations, when the user knows that the
connections between server and client break often. This needs a lot of
changes in the PG backend, I guess. And it may cost performance, so please
only as compile time switch.

Because someone mentioned MySQL as positive example: that's wrong. MySQL *can
not* handle broken/cloded connections, when the remote machine is gone (e.g.
firewalled or unplugged). I had this scenario some weeks ago: the client was
sending queries to the server, and the firewall blocked them (because before
this query the socket was about 5 minutes idle); the whole application was
blocked.

Ciao
Alvar

Alvar C.H. Freude -- http://alvar.a-blast.org/
http://odem.org/
http://www.assoziations-blaster.de/info/Hommingberger-Gepardenforelle.html
http://www.assoziations-blaster.de/

Browse pgsql-hackers by date

  From Date Subject
Next Message Rosser Schwarz 2005-05-02 20:58:16 Re: [HACKERS] Decision Process WAS: Increased company
Previous Message Andrew Dunstan 2005-05-02 20:53:59 Re: [pgsql-advocacy] Increased company involvement