Skip site navigation (1) Skip section navigation (2)

Re: Getting results after networking error

From: jtv(at)xs4all(dot)nl
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: jtv(at)xs4all(dot)nl, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Getting results after networking error
Date: 2005-08-10 03:51:48
Message-ID: 17553.202.47.227.25.1123645908.squirrel@202.47.227.25 (view raw or flat)
Thread:
Lists: pgsql-interfaces
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

Attachment: fe-misc.patch
Description: text/x-patch (645 bytes)

In response to

pgsql-interfaces by date

Next:From: William ZHANGDate: 2005-08-10 06:15:43
Subject: Re: BUG #1815: ECPGdebug causes crash on Windows XP
Previous:From: Joshua D. DrakeDate: 2005-08-10 03:28:13
Subject: Re: pgperl vs dbd-perl

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group