pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedDocumentation improvement for PQgetResult
3+ messages / 3 participants
[nested] [flat]
* Documentation improvement for PQgetResult
@ 2010-08-06 13:53 Daniele Varrazzo <daniele.varrazzo@gmail.com>
2010-08-06 14:20 ` Re: Documentation improvement for PQgetResult Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 3+ messages in thread
From: Daniele Varrazzo @ 2010-08-06 13:53 UTC (permalink / raw)
To: pgsql-docs; +Cc: Marko Kreen <markokr@gmail.com>
Hello,
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? Would it be better to perform a check
on the connection or on the result?
Thank you, cheers.
-- Daniele
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Documentation improvement for PQgetResult
2010-08-06 13:53 Documentation improvement for PQgetResult Daniele Varrazzo <daniele.varrazzo@gmail.com>
@ 2010-08-06 14:20 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-08-09 17:21 ` Re: Documentation improvement for PQgetResult Marko Kreen <markokr@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2010-08-06 14:20 UTC (permalink / raw)
To: Daniele Varrazzo <daniele.varrazzo@gmail.com>; +Cc: pgsql-docs@postgresql.org, Marko Kreen <markokr@gmail.com>
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.
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Documentation improvement for PQgetResult
2010-08-06 13:53 Documentation improvement for PQgetResult Daniele Varrazzo <daniele.varrazzo@gmail.com>
2010-08-06 14:20 ` Re: Documentation improvement for PQgetResult Tom Lane <tgl@sss.pgh.pa.us>
@ 2010-08-09 17:21 ` Marko Kreen <markokr@gmail.com>
0 siblings, 0 replies; 3+ messages in thread
From: Marko Kreen @ 2010-08-09 17:21 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Daniele Varrazzo <daniele.varrazzo@gmail.com>; pgsql-docs
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
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2010-08-09 17:21 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2010-08-06 13:53 Documentation improvement for PQgetResult Daniele Varrazzo <daniele.varrazzo@gmail.com>
2010-08-06 14:20 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-08-09 17:21 ` Marko Kreen <markokr@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox