Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group