Re: Add Pipelining support in psql
От | Michael Paquier |
---|---|
Тема | Re: Add Pipelining support in psql |
Дата | |
Msg-id | aAiTCkrKRroAPJOq@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Add Pipelining support in psql (Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>) |
Ответы |
Re: Add Pipelining support in psql
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: