Hi,

-- adnandursun@asrinbilisim.com.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/i...enforelle.html
http://www.assoziations-blaster.de/




---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly