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

From: "Murray S(dot) Kucherawy" <msk(at)cloudmark(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5837: PQstatus() fails to report lost connection
Date: 2011-01-24 17:26:36
Message-ID: F5833273385BB34F99288B3648C4F06F1341E73FCB@EXCH-C2.corp.cloudmark.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Monday, January 24, 2011 7:30 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
>
> "Murray S. Kucherawy" <msk(at)cloudmark(dot)com> writes:
> > Given what you say here, this seems to be an exception for which there
> > is currently no detection mechanism short of looking for that one
> > specific error string indicating it was administrative action causing
> > the error.
>
> 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.

Please, at a minimum, add some documentation about it.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2011-01-24 17:41:36 Re: BUG #5837: PQstatus() fails to report lost connection
Previous Message Tom Lane 2011-01-24 15:29:41 Re: BUG #5837: PQstatus() fails to report lost connection