Re: Documentation improvement for PQgetResult

On 8/6/10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Daniele Varrazzo <daniele.varrazzo@gmail.com> writes:
>  > documentation about the PQgetResult function suggests to "[call]
>  > repeatedly until it returns a null pointer, indicating that the
>  > command is done". This has lead psycopg developers to write code with
>  > the pattern:
>
>  >     while (NULL != (res = PQgetResult(conn))) {
>  >         /* do something with res */
>  >         PQclear(res);
>  >     }
>
>  > Marko Kreen has pointed out
>  > (http://lists.initd.org/pipermail/psycopg/2010-July/007149.html) that
>  > this can lead to an infinite loop if the connection goes bad at the
>  > rightly wrong time, advising then to check for the connection status
>  > in the middle of the loop. libpq code seems actually returning
>  > PQmakeEmptyPGresult(conn, PGRES_FATAL_ERROR) in case of something
>  > unexpected.
>
>  > If this is the case (I've not managed to reproduce it but the libpq
>  > code seems clear), shouldn't the function documentation warn for this
>  > risk, advising to check the connection status in the middle of the
>  > loop and bail out if it's bad?
>
>
> No.
>
>  I'm not convinced we need to do anything about that, since AFAIR no one
>  has ever reported such a failure from the field (which might well
>  indicate that Marko's analysis is wrong, anyway).  But if we were to do
>  something about it, changing the documentation would be the wrong
>  response, because that coding pattern is all over the place.  It'd be
>  better to kluge PQgetResult so it only returns a bad-connection error
>  object once per query, or something like that.

So the PQgetResult currently does not guarantee that, yes?
As that's what I noticed...

Few facts that I have:
- psycopg2 was in such loop.
- libpq [8.4.2] issued close(-1) per PQgetResult call.
  Due to accident, it was without debug symbols, so I could not
  analyze deeply.
- There were 2 processes in such state.
- NIC problem - corrupted the stream after multi-GB data transfer,
  but not always.  In this case, there were large COPY-ing
  going on.
- There were 5 dbs in the machine that were copying data.  Some
  of them failed with data-format error, some perhaps succeeded.
- The NIC has been changed, so its probably not reproducible easily.

--
marko