Re: Fix error handling in getCopyDataMessage and pqFunctionCall3 - Mailing list pgsql-hackers

Thanks for the reviews!

On Thu, Jul 23, 2026 at 9:43 AM Fujii Masao <masao.fujii@gmail.com> wrote:
> + /*
> + * An error may have been triggered while processing the message, bail
> + * out
> + */
> + if (conn->error_result && conn->status == CONNECTION_BAD)
> + return pqPrepareAsyncResult(conn);
>
> getCopyDataMessage() checks for the fatal error before pqParseDone(),
> but pqFunctionCall3() does it after pqParseDone().  Shouldn't
> pqFunctionCall3() use the same ordering?
>
> If getNotify() or getParameterStatus() calls handleFatalError(), the input
> buffer has already been flushed, so calling pqParseDone() afterwards seems
> unnecessary and a bit confusing.

Right, I guess one possible reason would be to trace the message. But
on the other hand, pqParseDone is called for successfully parsed
messages, and other codepaths don't call pqParseDone on errors, so it
is definitely confusing.

I've updated the patch to move the error checks before pqParseDone in
both cases.

Regards,
Anthonin Bonnefoy