Message-ID: <21028.202.47.227.25.1120571298.squirrel@202.47.227.25>
Date: Tue, 5 Jul 2005 15:48:18 +0200 (CEST)
Subject: libpq and connection failures
From: jtv@xs4all.nl
To: pgsql-interfaces@postgresql.org
User-Agent: SquirrelMail/1.4.3a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Is there any reason why pqReadData() (interfaces/libpq/fe-misc.c), if
pqsecure_read() fails with an error that isn't special-cased as a
transient one, returns -1 but leaves the connection state at
CONNECTION_OK?  Was this meant to be caught by calling pqReadReady()
(which doesn't happen in this case because of the return)?

Some libpqxx users with postgres 8.0 installed have observed broken
backend connections leading to errors but not updating connection state
accordingly.  One user unplugged his network cable, leading to a long
timeout followed by the error message "could not receive data from
server," but libpqxx was unable to diagnose the situation because
PQstatus() blithely returned CONNECTION_OK.

Doesn't it make more sense in these cases to "goto definitelyFailed"
instead of "return -1" as it does now?

This occurs in two places BTW, so it may make sense to refactor the
function before changing it: the code blocks at labels retry3 and retry4
are completely identical AFAICS except for one small "if" clause (plus a
variable is replaced by 0 where it's provably equal to zero).  Each is
really a switch within a loop, disguised as a nested if through cunning
use of goto.


Jeroen