libpq and connection failures - Mailing list pgsql-interfaces

From jtv@xs4all.nl
Subject libpq and connection failures
Date
Msg-id 21028.202.47.227.25.1120571298.squirrel@202.47.227.25
Whole thread Raw
Responses Re: libpq and connection failures  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-interfaces
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




pgsql-interfaces by date:

Previous
From: jtv@xs4all.nl
Date:
Subject: libpq: pqReadReady() / pqWriteReady()
Next
From: Tom Lane
Date:
Subject: Re: libpq and connection failures