Re: BUG #5837: PQstatus() fails to report lost connection

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Monday, January 24, 2011 9:42 AM
> To: Murray S. Kucherawy
> Cc: Robert Haas; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #5837: PQstatus() fails to report lost connection
>=20
> >> This is complete nonsense.  If you followed the documented method for
> >> using PQgetResult -- ie, keep calling it till it returns NULL, rather
> >> than assuming there will be a specific number of results --- then
> >> PQstatus would show you the bad status afterwards.
>=20
> > Your assertion here of "Read the result set to exhaustion, THEN check
> > connection status to see if it was bad to begin with," can be politely
> > described as counter-intuitive.
>=20
> [ shrug... ]  I guess if your intuition is that PQstatus should be
> expected to intuit the failure of a call that hasn't happened yet,
> then it's counter-intuitive.

You're mixing internal implementation details with what the API consumer se=
es.  I don't expect PQstatus() to do anything other than tell me that a con=
nection is no longer usable, which is what it's documented to do.  I'm fine=
 with checking it after an error has been returned by some query-related fu=
nction, which is what OpenDBX is doing.  I don't know why that's "complete =
nonsense".

Look at the order of operations here:

0) A previous connection exists.  The server is manually restarted.

1) A query is issued.  This succeeds.

2) A request for results is issued.  This returns non-NULL, apparently indi=
cating at least one result object came back.

3) PQresultStatus() is called, and it returns PGRES_FATAL_ERROR.

4) PQstatus() is checked, and indicates no problem.

4a) A call to PQresultErrorMessage() indicates that the library knows the c=
onnection was administratively reset.

As a consumer of the API, not knowing (or wanting to know) what's going on =
under-the-hood, this looks like a bug; the library certainly did know that =
the connection can no longer be used or 4a wouldn't happen, but PQstatus() =
is not saying so.  The documentation I see at http://www.postgresql.org/doc=
s/9.0/interactive/libpq-status.html doesn't lead me to believe that any of =
this logic is faulty.  That I have to iterate on step 2 above to get PQstat=
us() to eventually tell me the truth even though I know something has gone =
wrong already seems strange, and that's why I raised this issue.

Another possible explanation is that PQresultStatus() doesn't give a consis=
tent result until after PQgetResult() has returned NULL.  If that's the cas=
e, it should be documented, because right now it isn't.

-MSK