Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 206819FA0FB for ; Thu, 30 Nov 2006 10:13:01 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 29271-03 for ; Thu, 30 Nov 2006 10:12:54 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from smtp-02.arnet.com.ar (smtp-02.arnet.com.ar [200.45.191.22]) by postgresql.org (Postfix) with SMTP id 2007B9FA0CC for ; Thu, 30 Nov 2006 10:12:53 -0400 (AST) Received: (qmail 30312 invoked from network); 30 Nov 2006 09:13:24 -0000 Received: from unknown (HELO mail.integratech.net) (190.30.4.45) by smtp-02.arnet.com.ar with SMTP; 30 Nov 2006 09:13:24 -0000 Received: from [192.168.0.77] (azazel.integratech.net [192.168.0.77]) by mail.integratech.net (Postfix) with ESMTP id 4A8FF67D05; Thu, 30 Nov 2006 11:12:50 -0300 (ART) Message-ID: <456EE67C.3050501@integratech.com.ar> Date: Thu, 30 Nov 2006 11:11:08 -0300 From: Leandro Lucarella Organization: Integratech User-Agent: IceDove 1.5.0.8 (X11/20061123) MIME-Version: 1.0 To: "Jeroen T. Vermeulen" CC: Tomasz Myrta , pgsql-interfaces@postgresql.org, libpqxx-general@gborg.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> In-Reply-To: <17164.125.24.223.202.1164868383.squirrel@webmail.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.186 tagged_above=0 required=5 tests=AWL, BAYES_50, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200611/19 X-Sequence-Number: 6334 Jeroen T. Vermeulen escribió: > On Thu, November 30, 2006 03:31, Tomasz Myrta wrote: > >> I used keepalive the same way as you (reconfiguring socket directly) and >> I don't remember libpq trying to reconnect itself. I think it's a >> libpqxx's behaviour - I didn't use it, but it looks like it is called >> "reactivation". > > That's right. It's libpqxx, not libpq, that restores the connection. (It > couldn't really be any other way because libpq doesn't have enough > information to know it's safe--you could be in the middle of a > transaction, or you could be losing a temp table). Automatic reactivation > can also be disabled explicitly if you don't want it (or just *when* you > don't want it--e.g. when you're working with temp tables). > > I do think that the long TCP timeouts are something that should be handled > at the lower levels. We can't really do real keepalives, I guess, simply > because libpq is synchronous to the application. But perhaps we could > demand that the server at least acknowledge a request in some way within a > particular time limit? It'd have to be at the lowest level possible and > as "cheap" as possible, so it doesn't break when the server is merely very > busy. 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 =) -- Leandro Lucarella Integratech S.A. 4571-5252