> -----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
