Tom Lane wrote:
>>> I think it's probably better to have the default assumption be
>>> "connection possibly recoverable" than have it be "summarily kill
>>> connection at first hint of trouble". The latter seems less robust
>>> not more so.
>
>> Not after the connection failure has made its way into a PGresult,
>> surely?
>
> Well, I've not had a whole lot of personal experience with flaky
> connections to a database ... what do other people think would be
> the most useful behavior?
I can only speak for libpqxx and some of its users. One has pulled a
network cable out and found that the error he ultimately received (after a
long timeout) looked like a query failure--and PQstatus still said
CONNECTION_OK, leaving libpqxx unable to diagnose the error type and throw
the appropriate exception type. Searching for the error text brought us
to the scene of the crime.
I don't see how this state of affairs can be acceptable *at all* given
that PQstatus exists and purports to report a connection's status. If
pulling out the network cable and not putting it back fails to meet our
definition of a broken connection, what meets it?
Another user ran into trouble because he couldn't connect to the database
due to an incorrectly formatted connection string, but didn't receive an
error. Instead he got a PGconn that as far as I can make out, seemed
fully functional (non-NULL and CONNECTION_OK), but wasn't. We happened to
discover what was going on because he printed out the result of PQdb()
without checking for a NULL result, and reported the resulting crash to
the libpqxx mailing list.
Jeroen
