X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 6EFC352A0A for ; Wed, 10 Aug 2005 00:52:01 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 22124-01 for ; Wed, 10 Aug 2005 03:51:51 +0000 (GMT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by svr1.postgresql.org (Postfix) with ESMTP id D34A452A04 for ; Wed, 10 Aug 2005 00:51:49 -0300 (ADT) Received: from webmail.xs4all.nl (webmail12.xs4all.nl [194.109.22.172]) by smtp-vbr4.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7A3phwK068075; Wed, 10 Aug 2005 05:51:48 +0200 (CEST) (envelope-from jtv@xs4all.nl) Received: from 202.47.227.25 by webmail.xs4all.nl with HTTP; Wed, 10 Aug 2005 05:51:48 +0200 (CEST) Message-ID: <17553.202.47.227.25.1123645908.squirrel@202.47.227.25> In-Reply-To: <21820.1123643273@sss.pgh.pa.us> References: <4395.210.86.147.191.1123600604.squirrel@210.86.147.191> <16904.1123604812@sss.pgh.pa.us> <6201.202.47.227.25.1123640679.squirrel@202.47.227.25> <21820.1123643273@sss.pgh.pa.us> Date: Wed, 10 Aug 2005 05:51:48 +0200 (CEST) Subject: Re: Getting results after networking error From: jtv@xs4all.nl To: "Tom Lane" Cc: jtv@xs4all.nl, pgsql-interfaces@postgresql.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20050810055148_99377" X-Virus-Scanned: by XS4ALL Virus Scanner X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.228 tagged_above=0 required=5 tests=FORGED_RCVD_HELO, NO_REAL_NAME X-Spam-Level: X-Archive-Number: 200508/11 X-Sequence-Number: 5682 ------=_20050810055148_99377 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Tom Lane wrote: > I think that a reasonable API for this "if PQstatus(conn) is > CONNECTION_BAD then you had a networking problem". I am not at all sure > how well libpq honors that definition currently ... but feel free to > send patches ;-) As I posted in July, http://archives.postgresql.org/pgsql-interfaces/2005-07/msg00003.php the current situation is that libpq goes out of its way to maintain CONNECTION_OK in these cases. I'd still like to see the fix I outlined there, which is to treat socket errors as fatal by default (apart from the special cases for EAGAIN, EINTR and friends that are already there, of course). I'm attaching a patch; something similar may be called for in pqSendSome() as well. A next step would be to factor the code duplication out of the function, eliminating the redundant error message in the process. Jeroen ------=_20050810055148_99377 Content-Type: text/x-patch; name="fe-misc.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="fe-misc.patch" --- src/interfaces/libpq/fe-misc.c.org 2005-08-10 10:46:47.000000000 +0700 +++ src/interfaces/libpq/fe-misc.c 2005-08-10 10:48:38.000000000 +0700 @@ -610,7 +610,7 @@ printfPQExpBuffer(&conn->errorMessage, libpq_gettext("could not receive data from server: %s\n"), SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf))); - return -1; + goto definitelyFailed: } if (nread > 0) { @@ -701,7 +701,7 @@ printfPQExpBuffer(&conn->errorMessage, libpq_gettext("could not receive data from server: %s\n"), SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf))); - return -1; + goto definitelyFailed: } if (nread > 0) { ------=_20050810055148_99377--