diff options
author | Michael Paquier <michael@paquier.xyz> | 2025-06-04 09:01:29 +0900 |
---|---|---|
committer | Michael Paquier <michael@paquier.xyz> | 2025-06-04 09:01:29 +0900 |
commit | 7f3381c7ee661e552634f06509a3452988a15845 (patch) | |
tree | 2492dc89f56f21ec9522a819ed063e898c3a29c6 /src/test/perl/SimpleTee.pm | |
parent | 58fbfde152b28ca119fef4168550a1a4fef61560 (diff) | |
download | postgresql-master.tar.gz postgresql-master.zip |
When the backend reads COPY data, it ignores all sync messages, as per
c01641f8aed0. With psql pipelines, it is possible to manually send sync
messages with \sendpipeline which leaves the frontend in an
unrecoverable state as the backend will not send the necessary
ReadyForQuery message that is expected to feed psql result consumption
logic.
It could be possible to artificially reduce the piped_syncs and
requested_results, however libpq's state would still have queued sync
messages in its command queue, and the only way to consume those without
directly calling pqCommandQueueAdvance() is to process ReadyForQuery
messages that won't be sent since the backend ignores these. Perhaps
this could be improved in the future, but I am not really excited about
introducing this amount of complications in libpq to manipulate the
message queues without a better use case to support it.
Hence, this patch aborts the connection if we detect excessive sync
messages after a COPY in a pipeline to avoid staying in an inconsistent
protocol state, which is the best thing we can do with pipelines in
psql for now. Note that this change does not prevent wrapping a set
of queries inside a block made of \startpipeline and \endpipeline, only
the use of \syncpipeline for a COPY.
Reported-by: Nikita Kalinin <n.kalinin@postgrespro.ru>
Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Discussion: https://postgr.es/m/18944-8a926c30f68387dd@postgresql.org
Diffstat (limited to 'src/test/perl/SimpleTee.pm')
0 files changed, 0 insertions, 0 deletions