> -----Original Message----- > From: Tom Lane [mailto:t...@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 > > >> 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
