Re: BUG #5837: PQstatus() fails to report lost connection
От | Bruce Momjian |
---|---|
Тема | Re: BUG #5837: PQstatus() fails to report lost connection |
Дата | |
Msg-id | 201103111056.p2BAu1L22204@momjian.us обсуждение исходный текст |
Ответ на | Re: BUG #5837: PQstatus() fails to report lost connection (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: BUG #5837: PQstatus() fails to report lost connection
(Robert Haas <robertmhaas@gmail.com>)
|
Список | pgsql-bugs |
Robert Haas wrote: > On Tue, Jan 25, 2011 at 10:54 AM, Kevin Grittner > <Kevin.Grittner@wicourts.gov> wrote: > > Robert Haas <robertmhaas@gmail.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 > > IIUC, Tom's point was that doing it that way would detect the error, > not that it was the ONLY way to detect the error. > > But it's easily testable. > > >> 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. > > That is why I suggested the type of doc correction that I thought > would be most helpful and accurate. Doc patch attached and applied. I used "should be called" instead of "must". -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml new file mode 100644 index 49edc51..59b4011 *** a/doc/src/sgml/libpq.sgml --- b/doc/src/sgml/libpq.sgml *************** PGresult *PQgetResult(PGconn *conn); *** 3846,3851 **** --- 3846,3860 ---- active and the necessary response data has not yet been read by <function>PQconsumeInput</function>. </para> + + <note> + <para> + Even when <function>PQresultStatus</function> indicates a fatal + error, <function>PQgetResult</function> should be called until it + returns a null pointer to allow <application>libpq</> to + process the error information completely. + </para> + </note> </listitem> </varlistentry> </variablelist>
В списке pgsql-bugs по дате отправления:
Предыдущее
От: Bruce MomjianДата:
Сообщение: Re: BUG #5857: pg_restore --clean dropping type too soon