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:

Previous
From: TAKATSUKA Haruka
Date:
Subject: Re: BUG #18952: pg_restore --help and document have strange description: Dump something
Next
From: Anthonin Bonnefoy
Date:
Subject: Re: BUG #18944: Assertion Failure in psql with idle_session_timeout Set