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
