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