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
Следующее
От: "Castro"
Дата:
Сообщение: BUG #5925: Files corrupted