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

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Monday, January 24, 2011 9:42 AM
> To: Murray S. Kucherawy
> Cc: Robert Haas; pgsql-bugs(at)postgresql(dot)org
> Subject: Re: [BUGS] BUG #5837: PQstatus() fails to report lost connection
>
> >> 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.
>
> > 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.
>
> [ 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 sees. I don't expect PQstatus() to do anything other than tell me that a connection 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 function, 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 indicating 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 connection 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/docs/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 PQstatus() 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 consistent result until after PQgetResult() has returned NULL. If that's the case, it should be documented, because right now it isn't.

-MSK