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

On Tue, Jan 25, 2011 at 12:01 PM, Murray S. Kucherawy <msk(at)cloudmark(dot)com> wrote:
>> -----Original Message-----
>> From: Robert Haas [mailto:robertmhaas(at)gmail(dot)com]
>> Sent: Tuesday, January 25, 2011 7:33 AM
>> To: Kevin Grittner
>> Cc: Murray S. Kucherawy; Tom Lane; pgsql-bugs(at)postgresql(dot)org
>> Subject: Re: [BUGS] BUG #5837: PQstatus() fails to report lost connection
>>
>> 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.
>
> First and foremost, I think a behavior change would be the right thing to do.  I can't think of any API that follows this odd model; to me it's like saying select() has reported a socket that's both read-ready and in an exception state, but we won't actually set errno until you iterate on read() until EOF first.  Counter-intuitive behaviors in APIs lead to application problems or even user attrition in extreme cases.

libpq is odd and clunky on many levels; it's old, but it's also very
rich and useful. many people here would admit that given infinite time
and resources it could use a rewrite. however. this is not high at
all on the priority list because at the end of the day you can make it
do just about anything you really need it to do, and the old api would
have to be maintained for a good while.

just wrap the behavior you don't like out -- libpq simply demands a
good set of wrappers unfortunately.

merlin