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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Murray S(dot) Kucherawy" <msk(at)cloudmark(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: BUG #5837: PQstatus() fails to report lost connection
Date: 2011-01-25 15:54:05
Message-ID: 4D3E9DBD0200002500039C36@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> I think this patch would only be adding to the confusion. When
> PQgetResult() is called, we read enough data from the connection
> to create and return one result object. It's true that this
> doesn't necessarily detect an EOF, but IIUC calling PQgetResult()
> again is just ONE way that you could trigger another read against
> the socket, not the only one. I think it would also work to call
> PQconsumeInput(), for example.

I find it hard to reconcile the above with this:

http://archives.postgresql.org/message-id/6493.1295882981@sss.pgh.pa.us

and the quote from our documentation referenced here:

http://archives.postgresql.org/message-id/4D3D67600200002500039B2C@gw.wicourts.gov

> I think the real, underlying problem here is that Murray would
> like a behavior change

More than that I think he wants to be able to read the manual and
know what will work, without spending loads of time getting in tune
with The Tao of Libpq. Based on his initial reading of the docs he
expected different behavior; that can be fixed by changing the
behavior or changing the docs.

-Kevin

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Murray S. Kucherawy 2011-01-25 18:01:58 Re: BUG #5837: PQstatus() fails to report lost connection
Previous Message Robert Haas 2011-01-25 15:32:41 Re: BUG #5837: PQstatus() fails to report lost connection