From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: libpq async duplicate error results
Date: Thu, 03 Feb 2022 11:04:33 -0500
Message-ID: <269608.1643904273@sss.pgh.pa.us> (raw)
In-Reply-To: <22d52a5b-31ce-d951-1f5f-3403d793cec3@enterprisedb.com>
References: <ab4288f8-be5c-57fb-2400-e3e857f53e46@enterprisedb.com>
<22d52a5b-31ce-d951-1f5f-3403d793cec3@enterprisedb.com>
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> Tom, you worked on reorganzing the error message handling in libpq in
> PostgreSQL 14 (commit ffa2e4670123124b92f037d335a1e844c3782d3f). Any
> thoughts on this?
Ah, sorry, I'd not noticed this thread.
I concur with Fabien's analysis: we report the FATAL message from
the server during the first PQgetResult, and then the second call
discovers that the connection is gone and reports "server closed
the connection unexpectedly". Those are two independent events
(in libpq's view anyway) so reporting them separately is correct,
or at least necessary unless you want to engage in seriously
major redesign and behavioral changes.
It is annoying that some of the text is duplicated in the second
report, but in the end that's cosmetic, and I'm not sure we can
improve it without breaking other things. In particular, we
can't just think about what comes back in the PGgetResult calls,
we also have to consider what PQerrorMessage(conn) will report
afterwards. So I don't think that resetting conn->errorMessage
during a PQgetResult series would be a good fix.
An idea that I don't have time to pursue right now is to track
how much of conn->errorMessage has been read out by PQgetResult,
and only report newly-added text in later PQgetResult calls of
a series, while PQerrorMessage would continue to report the
whole thing. Buffer resets would occur where they do now.
It'd probably be necessary to make a user-visible PQgetResult
that becomes a wrapper around PQgetResultInternal, because
internal callers such as PQexecFinish will need the old behavior,
or at least some of them will.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, peter.eisentraut@enterprisedb.com, coelho@cri.ensmp.fr
Subject: Re: libpq async duplicate error results
In-Reply-To: <269608.1643904273@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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