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

libpq and connection failures

From: jtv(at)xs4all(dot)nl
To: pgsql-interfaces(at)postgresql(dot)org
Subject: libpq and connection failures
Date: 2005-07-05 13:48:18
Message-ID: 21028.202.47.227.25.1120571298.squirrel@202.47.227.25 (view raw or flat)
Thread:
Lists: 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



Responses

pgsql-interfaces by date

Next:From: Tom LaneDate: 2005-07-05 14:43:09
Subject: Re: libpq and connection failures
Previous:From: jtvDate: 2005-07-05 13:41:37
Subject: libpq: pqReadReady() / pqWriteReady()

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