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@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 <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