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 9C52152C5D
	for <pgsql-interfaces-postgresql.org@localhost.postgresql.org>;
	Wed, 10 Aug 2005 00:08:03 -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 73199-07
	for <pgsql-interfaces-postgresql.org@localhost.postgresql.org>;
	Wed, 10 Aug 2005 03:07:55 +0000 (GMT)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by svr1.postgresql.org (Postfix) with ESMTP id 2ECB4529B7
	for <pgsql-interfaces@postgresql.org>;
	Wed, 10 Aug 2005 00:07:54 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j7A37rTQ021821;
	Tue, 9 Aug 2005 23:07:54 -0400 (EDT)
To: jtv@xs4all.nl
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Getting results after networking error 
In-reply-to: <6201.202.47.227.25.1123640679.squirrel@202.47.227.25> 
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>
Comments: In-reply-to jtv@xs4all.nl
	message dated "Wed, 10 Aug 2005 04:24:39 +0200"
Date: Tue, 09 Aug 2005 23:07:53 -0400
Message-ID: <21820.1123643273@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.006 tagged_above=0 required=5 tests=AWL
X-Spam-Level: 
X-Archive-Number: 200508/9
X-Sequence-Number: 5680

jtv@xs4all.nl writes:
> Tom Lane wrote:
>> On the whole I think the odds of re-syncing successfully are pretty bad,
>> and you'd be best off to pull the plug and start a new connection if you
>> see any networking failure.

> I guess that makes sense.  But how do I know that the failure is a
> networking failure and not, say, an SQL-level failure?  In my program, I
> mean, without human intervention?

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 ;-)

			regards, tom lane