Re: BUG #18944: Assertion Failure in psql with idle_session_timeout Set

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(at)entry=6,
no_tid=no_tid(at)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(at)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(at)entry=0xbd8dd0c47fd0 "res == ((void *)0) || result_status == PGRES_PIPELINE_ABORTED", file=file(at)entry=0xbd8dd0c47eb0 "common.c", line=line(at)entry=1527,
function=function(at)entry=0xbd8dd0c76068 <__PRETTY_FUNCTION__.3> "discardAbortedPipelineResults")
at ./assert/assert.c:96
#5 0x0000e89cda865d30 in __assert_fail (
assertion=assertion(at)entry=0xbd8dd0c47fd0 "res == ((void *)0) || result_status == PGRES_PIPELINE_ABORTED", file=file(at)entry=0xbd8dd0c47eb0 "common.c", line=line(at)entry=1527,
function=function(at)entry=0xbd8dd0c76068 <__PRETTY_FUNCTION__.3> "discardAbortedPipelineResults")
at ./assert/assert.c:105
#6 0x0000bd8dd0bfe6a8 in discardAbortedPipelineResults () at common.c:1527
#7 ExecQueryAndProcessResults (query=query(at)entry=0xbd8df7065330 "COPY psql_pipeline FROM STDIN;",
elapsed_msec=elapsed_msec(at)entry=0xffffd1a532e0, svpt_gone_p=svpt_gone_p(at)entry=0xffffd1a532df,
is_watch=is_watch(at)entry=false, min_rows=min_rows(at)entry=0, opt=opt(at)entry=0x0,
printQueryFout=printQueryFout(at)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(at)entry=0xe89cda9e0880 <_IO_2_1_stdin_>)
at mainloop.c:515
#10 0x0000bd8dd0bf7070 in process_file (filename=0x0,
use_relative_path=use_relative_path(at)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 <http://www.postgrespro.com/>
The Russian Postgres Company

> On 4 Jun 2025, at 07:12, Michael Paquier <michael(at)paquier(dot)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