From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com> |
Cc: | "a(dot)kozhemyakin" <a(dot)kozhemyakin(at)postgrespro(dot)ru>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add Pipelining support in psql |
Date: | 2025-04-23 07:13:14 |
Message-ID: | aAiTCkrKRroAPJOq@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 22, 2025 at 02:37:19PM +0200, Anthonin Bonnefoy wrote:
> 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.
Right. I didn't think about the case of a \endpipeline that fetches
all the results by itself.
> 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.
Sounds like a better idea seen from here, yes.
> 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.
Hmm. I vaguely recall that there could be some race condition here
with the attempt to catch up the FATAL message once the server tries
to shut down the connection..
Anyway, I agree that it would be nice to track that this specific
error message is generated in the server. How about checking the
server logs instead, using a slurp_file() with an offset of the log
file before running each pipeline sequence? We should use a few
wait_for_log() calls, I think, to be extra careful with the timings
where psql_fails_like() gives up, and I'm worried that this could be
unstable on slow machines. Something like the attached seems stable
enough here. What do you think?
The tweak for psql_fails_like() was kind of independent of the rest of
the fix, so I have applied that as a commit of its own. I am not
convinced about the addition of a 4th test where we use the queries
with semicolons without a \getresults between the sync and the end.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
v3-0001-psql-Fix-assertion-failure-with-pipeline-mode.patch | text/x-diff | 3.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Frédéric Yhuel | 2025-04-23 07:41:58 | Re: [BUG] temporary file usage report with extended protocol and unnamed portals |
Previous Message | Amit Kapila | 2025-04-23 06:31:37 | Re: long-standing data loss bug in initial sync of logical replication |