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

On Mon, Jan 24, 2011 at 1:47 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> "Murray S. Kucherawy" <msk@cloudmark.com> wrote:
>> From: Kevin Grittner [mailto:Kevin.Grittner@wicourts.gov]
>
>>> What do you think would make this more clear?
>
>> So maybe something like this after the paragraph you cited would
>> help:
>>
>> "Note that after returning a PGresult object, PQresultStatus()
>> could indicate a fatal error. =A0The caller should still iterate
>> calling PQgetResult() to completion (i.e. until it returns NULL)
>> in order to allow libpq to process the error information
>> completely."
>
> A patch based on this suggestion attached for consideration by the
> community.

I think this patch would only be adding to the confusion.  When
PQgetResult() is called, we read enough data from the connection to
create and return one result object.  It's true that this doesn't
necessarily detect an EOF, but IIUC calling PQgetResult() again is
just ONE way that you could trigger another read against the socket,
not the only one.  I think it would also work to call
PQconsumeInput(), for example.

I think the real, underlying problem here is that Murray would like a
behavior change: when a FATAL or PANIC condition is reported by the
server, he'd like the client to immediately close the socket and set
its status to CONNECTION_BAD.  If we're going to clarify the
documentation, I think that the lack of that behavior is what we
should try to clarify.  For example, it would be good to mention that
a PGRES_FATAL_ERROR is might corresponding to the server levels ERROR,
FATAL, or PANIC, and that only in the latter two cases is the
connection presumably of no further use; and we could also mention
that libpq doesn't understand anything about the meanings of those
error levels, so that PQstatus() won't automatically barf just because
the server has sent a FATAL, *unless* it's read far enough in the
input stream to detect the problem.

Perhaps, as Murray says, this is exposing an implementation detail.
But in my experience when coding against libraries written by other
people it's often necessary to have at least a superficial
understanding of what operations they are performing under the hood.
I don't think there's any way we can eliminate that problem
completely.  What we CAN try to do is make sure that the documentation
clearly explains enough of what's going on under the hood to allow
people to code against it successfully, without (hopefully) going
overboard into irrelevant details that the user doesn't need to care
about.

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company