Re: BUG #5837: PQstatus() fails to report lost connection - Mailing list pgsql-bugs

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Saturday, January 22, 2011 7:44 PM
> To: Robert Haas
> Cc: Murray S. Kucherawy; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #5837: PQstatus() fails to report lost connection
>=20
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Thu, Jan 13, 2011 at 8:36 PM, Murray S. Kucherawy <msk@cloudmark.com=
> wrote:
> >> 1) establish a connection to postgresql
> >> 2) initiate a query, collect results, etc.; all normal
> >> 3) while client is idle, restart the server
> >> 4) initiate the very same query as before
> >> 5) call PQgetResult(), returns non-NULL
> >> 6) call PQresultStatus(), returns PGRES_FATAL_ERROR
> >> 7) call PQstatus(), returns CONNECTION_OK
>=20
> I think the OP's mistake is to assume that the first PQgetResult ought
> to set this.  As you say, it hasn't discovered the EOF condition at the
> time it returns that error-message result, and we are certainly not
> going to add another kernel call to every query cycle to check for EOF.
>=20
> The reason I don't see a problem when using PQexec is that PQexec will
> internally do another PQgetResult, and it's the second one that will
> fail and reset the connection status.  In a non-connection-termination
> situation, the second internal PQgetResult call consumes the
> ReadyForQuery message, and at that point we fall out of PQexec (without
> any extra kernel call).  Here, though, there won't be a ReadyForQuery,
> and it's the read() to try to collect one that discovers the loss of
> connection.
>=20
> In short: I don't think there's a bug here, just failure to understand
> proper use of PQgetResult.

For the sake of context, I'm using opendbx which is a layer between my appl=
ication and any SQL backend it can support.  The code that hits this proble=
m is in there.  See http://www.linuxnetworks.de/doc/index.php/OpenDBX.  I'l=
l forward this thread to that code's maintainer.

As for the reply above, I disagree.  PQstatus(), as documented, doesn't say=
 anything about certain conditions in which it won't report that the connec=
tion is dead, when it actually is, once the connection was already establis=
hed and working.

I would also suggest that everything you're describing is internal details =
of libpq implementation and not stuff that should be visible to consumers o=
f libpq.  The level of knowledge described strikes me as the kind of thing =
your average libpq consumer shouldn't need to have; it's exactly why you wa=
nt to have a library providing this sort of service in the first place.

Moreover, the description of PQgetResult() doesn't say or illustrate anythi=
ng about proper use of it in this context, so how would a reader know he/sh=
e got it wrong?  The documentation I can find online of PQgetResult() doesn=
't enumerate the conditions where PQstatus() gives a false indication of wh=
ether or not a reconnect is required, nor does any part of the documentatio=
n I could find state that PGRES_FATAL_ERROR always implies the connection i=
s no longer usable and must be re-established; "FATAL" could be referring t=
o the transaction/request, not the connection.

So, if this isn't a bug, then I think the documentation needs a bit of work=
 in this area.

-MSK