Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id ABD949FA241 for ; Fri, 1 Dec 2006 12:13:01 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 29047-09 for ; Fri, 1 Dec 2006 12:12:53 -0400 (AST) X-Greylist: delayed 00:19:20.922489 by SQLgrey-1.7.4 Received: from smtp-02.arnet.com.ar (host191003.arnet.net.ar [200.45.191.3]) by postgresql.org (Postfix) with SMTP id 630A69FA12B for ; Fri, 1 Dec 2006 12:12:51 -0400 (AST) Received: (qmail 20353 invoked from network); 1 Dec 2006 10:46:28 -0000 Received: from unknown (HELO mail.integratech.net) (190.30.4.45) by 172.26.11.32 with SMTP; 1 Dec 2006 10:46:27 -0000 Received: from [192.168.0.77] (azazel.integratech.net [192.168.0.77]) by mail.integratech.net (Postfix) with ESMTP id 5D65367E27; Fri, 1 Dec 2006 12:46:09 -0300 (ART) Message-ID: <45704DD6.1040201@integratech.com.ar> Date: Fri, 01 Dec 2006 12:44:22 -0300 From: Leandro Lucarella Organization: Integratech User-Agent: IceDove 1.5.0.8 (X11/20061123) MIME-Version: 1.0 To: Leandro Lucarella CC: pgsql-interfaces@postgresql.org, pgsql-hackers@postgresql.org Subject: Re: Keep-alive support References: <456DE433.8000407@integratech.com.ar> <456DEE3D.3020108@klaster.net> <17164.125.24.223.202.1164868383.squirrel@webmail.xs4all.nl> <456EE67C.3050501@integratech.com.ar> In-Reply-To: <456EE67C.3050501@integratech.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/1 X-Sequence-Number: 6335 For pgsql-hackers, here is the original thread (I think this mail is appropriate for this list, correct me if I'm wrong): http://archives.postgresql.org/pgsql-interfaces/2006-11/msg00014.php Leandro Lucarella escribió: > Thanks all for your responses, but this is *not* a libpqxx issue, just > because I'm doing the test using plain libpq. Anyways, I have a little > more information about my problem and it's no libpq either =) > > The problem is shown when the time between the wire is unplugged and the > use of the connection is not long enough to let the keep-alive kill the > connection. Then the connection becomes active and the TCP timers looks > like go back to the defaults, because there is data in the socket queue > to send. So it's an OS/TCP issue. > > I don't see any way to control this without using an application-level > keep-alive, so I appreciate any ideas and suggestions =) Hi! It's me again =) I was thinking about solutions for my problem, and I've come up with (mainly) this 3 ideas: 1) Add TIPC[1] support to Postgresql. This is the cleaner solution, I think, but the the hardest and could take a lot of time, but if I use some of the other hacks in the meantime and if there is interest on adding this to Postgresql officially, I can evaluate working on this seriously. What I'm sure I don't want is to keep my own Postresql fork. So, what do you think about this? Or where should I ask? 2) Use a "monitor" dummy connection to postgres, do the TCP keep-alive tunning and select() the socket waiting for a disconnection. Since this socket will never be active (is that right? Or Postgresql sends any kind of control information on an idle connection?), the TCP keep-alive will be enough to determine if the connection is lost in a short period of time. If there is no problem with this, I think it could be a quick and not-so-nasty solution =) 3) Use Heartbeat[2] or make some other specific solution like it (probably using TIPC too). I don't like it at all, since I'm looking for a more self-contained solution, but it's another option. I really appreciate any thought on this, and any suggestions. TIA. [1] http://tipc.sourceforge.net/ [2] http://www.linux-ha.org/HeartbeatProgram -- Leandro Lucarella Integratech S.A. 4571-5252