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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
Cc: Никита Калинин <n(dot)kalinin(at)postgrespro(dot)ru>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18944: Assertion Failure in psql with idle_session_timeout Set
Date: 2025-06-11 22:34:52
Message-ID: aEoEjEsBFj62ywnE@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Jun 11, 2025 at 04:11:14PM +0200, Anthonin Bonnefoy wrote:
> Libpq's fe-exec doesn't seem to handle a possible pipeline state in
> PQputCopyEnd. Naively, I've tried to only send a Sync message if
> 'conn->pipelineStatus == PQ_PIPELINE_OFF' but this will block the
> client in Copy mode and the Sync message is needed to exit it.
> I didn't have time to look into this further today but a possible fix
> could be to send the Sync message and add it to the command queue if
> we're in a pipeline. This should allow libpq's state to get out of the
> aborted pipeline state and match the backend's state.

Hmm. The root issue is that we are trying to work around the
limitations of the existing result handling required by COPY and the
extended protocol which are both not interacting nicely as psql has
little idea that we are in a COPY state because we've sent a plain
COPY query (contrary to \copy, actually, where we could detect that
with a counter).

As this is the first release where these pipeline meta-commands exist,
we may want to consider a more restrictive measure to prevent this
state to happen to begin with, rather to try to implement workarounds.
I understand that it may not be the best thing to do, but we could
restrict the use of COPY in pipelines for the initial release of this
feature and just say that we don't support it for now. Then, in the
future, if somebody is interested, we could study how it is possible
to lift this restriction, but I suspect that we won't fly high without
some redesign of libpq in terms if pipeline queues, which has the risk
of introducing juicy bugs, but that would be a problem of the future.

So my point would be to take a drastic decision in
ExecQueryAndProcessResults() if we detect a PGRES_COPY_BOTH,
PGRES_COPY_OUT or PGRES_COPY_IN while in a pipeline, and just give up.
It does not prevent the feature to work for other queries, and we
still have test coverage for queries that cannot run in transaction
blocks like REINDEX CONCURRENTLY, etc. It just means that we cannot
enter in a COPY state while in a pipeline.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2025-06-11 23:46:26 Re: BUG #18947: TRAP: failed Assert("len_to_wrt >= 0") in pg_stat_statements
Previous Message Masahiko Sawada 2025-06-11 22:03:04 Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5