On Tue, Apr 22, 2025 at 2:06 AM Michael Paquier <mich...@paquier.xyz> wrote: > I am wondering if we could not be smarter with the handling of > the counters, but I really doubt that there is much more we can do > under a PGRES_FATAL_ERROR.
One thing that bothers me is that the reported error is silently discarded within discardAbortedPipelineResults. psql -f bug_assertion.sql psql:bug_assertion.sql:7: ERROR: unexpected message type 0x50 during COPY from stdin CONTEXT: COPY psql_pipeline, line 1 psql:bug_assertion.sql:7: Pipeline aborted, command did not run This should ideally report the "FATAL: terminating connection because protocol synchronization was lost" sent by the backend process. Also, we still have a triggered assertion failure with the following: CREATE TABLE psql_pipeline(a text); \startpipeline COPY psql_pipeline FROM STDIN; SELECT 'val1'; \syncpipeline \endpipeline ... Assertion failed: (pset.piped_syncs == 0), function ExecQueryAndProcessResults, file common.c, line 2153. A possible alternative could be to abort discardAbortedPipelineResults when we encounter a res != NULL + FATAL error and let the outer loop handle it. As you said, the pipeline flow is borked so there's not much to salvage. The outer loop would read and print all error messages until the closed connection is detected. Then, CheckConnection will reset the connection which will reset the pipeline state. While testing this change, I was initially looking for the "FATAL: terminating connection because protocol synchronization was lost" message in the tests. However, this was failing on Windows[1] as the FATAL message wasn't reported on stderr. I'm not sure why yet. [1]: https://cirrus-ci.com/task/5051031505076224?logs=check_world#L240-L246
v02-0001-PATCH-psql-Fix-assertion-failure-with-pipeline-m.patch
Description: Binary data
