Re: BUG #18944: Assertion Failure in psql with idle_session_timeout Set - Mailing list pgsql-bugs
From | Никита Калинин |
---|---|
Subject | Re: BUG #18944: Assertion Failure in psql with idle_session_timeout Set |
Date | |
Msg-id | AC468509-06E8-4E2A-A4B1-63046A4AC6AB@postgrespro.ru Whole thread Raw |
In response to | Re: BUG #18944: Assertion Failure in psql with idle_session_timeout Set (Michael Paquier <michael@paquier.xyz>) |
Responses |
Re: BUG #18944: Assertion Failure in psql with idle_session_timeout Set
|
List | pgsql-bugs |
Hello!
I do not believe it is necessary to create a new bug report, as, in my opinion, this issue remains a continuation of BUG #18944. Upon executing the following request:
psql <<EOF
CREATE TABLE psql_pipeline(a INTEGER PRIMARY KEY, s TEXT);
\startpipeline
COPY psql_pipeline FROM STDIN;
\flushrequest
\getresults
\endpipeline
\.
COPY psql_pipeline FROM STDIN;
\syncpipeline
\getresults
EOF
we encounter yet another assertion failure:
ERROR: invalid input syntax for type integer: "endpipeline"
CONTEXT: COPY psql_pipeline, line 1, column a: "endpipeline"
message type 0x5a arrived from server while idle
Pipeline aborted, command did not run
psql: common.c:1527: discardAbortedPipelineResults: Assertion `res == ((void *)0) || result_status == PGRES_PIPELINE_ABORTED' failed.
Aborted (core dumped).
Coredump:
#0 __pthread_kill_implementation (threadid=255760382287552, signo=signo@entry=6,
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1 0x0000e89cda8b7670 in __pthread_kill_internal (signo=6, threadid=<optimized out>)
at ./nptl/pthread_kill.c:78
#2 0x0000e89cda86cb3c in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x0000e89cda857e00 in __GI_abort () at ./stdlib/abort.c:79
#4 0x0000e89cda865cc0 in __assert_fail_base (
fmt=0xe89cda98c770 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0xbd8dd0c47fd0 "res == ((void *)0) || result_status == PGRES_PIPELINE_ABORTED", file=file@entry=0xbd8dd0c47eb0 "common.c", line=line@entry=1527,
function=function@entry=0xbd8dd0c76068 <__PRETTY_FUNCTION__.3> "discardAbortedPipelineResults")
at ./assert/assert.c:96
#5 0x0000e89cda865d30 in __assert_fail (
assertion=assertion@entry=0xbd8dd0c47fd0 "res == ((void *)0) || result_status == PGRES_PIPELINE_ABORTED", file=file@entry=0xbd8dd0c47eb0 "common.c", line=line@entry=1527,
function=function@entry=0xbd8dd0c76068 <__PRETTY_FUNCTION__.3> "discardAbortedPipelineResults")
at ./assert/assert.c:105
#6 0x0000bd8dd0bfe6a8 in discardAbortedPipelineResults () at common.c:1527
#7 ExecQueryAndProcessResults (query=query@entry=0xbd8df7065330 "COPY psql_pipeline FROM STDIN;",
elapsed_msec=elapsed_msec@entry=0xffffd1a532e0, svpt_gone_p=svpt_gone_p@entry=0xffffd1a532df,
is_watch=is_watch@entry=false, min_rows=min_rows@entry=0, opt=opt@entry=0x0,
printQueryFout=printQueryFout@entry=0x0) at common.c:1828
#8 0x0000bd8dd0bfc6d0 in SendQuery (query=0xbd8df7065330 "COPY psql_pipeline FROM STDIN;")
at common.c:1212
#9 0x0000bd8dd0c10d3c in MainLoop (source=source@entry=0xe89cda9e0880 <_IO_2_1_stdin_>)
at mainloop.c:515
#10 0x0000bd8dd0bf7070 in process_file (filename=0x0,
use_relative_path=use_relative_path@entry=false) at command.c:4870
#11 0x0000bd8dd0bf1b04 in main (argc=<optimized out>, argv=<optimized out>) at startup.c:420
Nikita Kalinin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 4 Jun 2025, at 07:12, Michael Paquier <michael@paquier.xyz> wrote:On Tue, Jun 03, 2025 at 11:56:51AM +0200, Anthonin Bonnefoy wrote:I've tried to adjust the piped syncs counter, but that's not enough.
libpq's internal command queue still has the Syncs queued and will
stay in a busy pipeline state if the backend doesn't send the expected
ReadyForQuery. It could be possible to remove them from the queue with
pqCommandQueueAdvance, but that would require psql to include
libpq-int.h which is probably something we want to avoid.
libpq-int.h is for internal purposes and should not be directly
used in frontends, so that's a no-go.It doesn't seem like this case can be handled gracefully. The provided
patch just aborts the connection from the frontend when excessive
piped syncs are detected to avoid staying stuck in this inconsistent
protocol state.
I have been spending some time trying to get psql to gracefully handle
this case, likely as you did by making ExecQueryAndProcessResults()
fail gracefully, but even reinitializing the counters is not enough
and I have also bumped into the libpq limitations. If somebody is
excited enough to justify exposing these APIs, perhaps they'll have a
good reason and a case to do so, but I'm not excited about doing that
for this psql tooling: we are still able to serialize commands within
a pipeline anyway.
For now I have applied your patch, adding one extra test with COPY TO
on top of the one with COPY FROM.
--
Michael
pgsql-bugs by date: