public inbox for [email protected]help / color / mirror / Atom feed
pgsql: psql: Fix issues with deferred errors in pipelines 2+ messages / 1 participants [nested] [flat]
* pgsql: psql: Fix issues with deferred errors in pipelines @ 2026-06-02 23:58 Michael Paquier <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Michael Paquier @ 2026-06-02 23:58 UTC (permalink / raw) To: [email protected] psql: Fix issues with deferred errors in pipelines When an error is raised while processing a Sync message in a pipeline, like a deferred constraint violation, the error was not associated with the piped command and was not counted in available_results. This caused assertion failures in discardAbortedPipelineResults(), keeping an incorrect state at pipeline exit, because the code assumed that the number of available and requested results would always be positive, expecting all the counters to be 0 at the end of a pipeline. This commit switches discardAbortedPipelineResults() and ExecQueryAndProcessResults() to take a softer approach when consuming and draining the results after an error. If there are still piped syncs in the pipeline when it ends, we now attempt to consume them before leaving the pipeline mode. Alexander has been able to reach two assertion failures through his testing. While investigating more this issue, I have bumped into two more. Most of these cases are covered by the regression tests added in this commit, plus some cases with mixes of pipelines, deferred errors and results fetched. Some of the tests discussed (like the backend termination one) could not be included in this commit but have been tested manually. Another test scenario discussed involved the injection of an error state in the backend, that was able to trick libpq internally and put its queue out of sync. This scenario is not going to happen in practice, but if we were to do something about it we would need to make libpq understand that it needs to fail in some cases but not block. Reported-by: Alexander Lakhin <[email protected]> Author: Michael Paquier <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 18 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/d21604e17e491eef39626a2eff518b9731fefb91 Modified Files -------------- src/bin/psql/common.c | 76 +++++++++++++---- src/test/regress/expected/psql_pipeline.out | 124 ++++++++++++++++++++++++++++ src/test/regress/sql/psql_pipeline.sql | 63 ++++++++++++++ 3 files changed, 245 insertions(+), 18 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: psql: Fix issues with deferred errors in pipelines @ 2026-06-02 23:58 Michael Paquier <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Michael Paquier @ 2026-06-02 23:58 UTC (permalink / raw) To: [email protected] psql: Fix issues with deferred errors in pipelines When an error is raised while processing a Sync message in a pipeline, like a deferred constraint violation, the error was not associated with the piped command and was not counted in available_results. This caused assertion failures in discardAbortedPipelineResults(), keeping an incorrect state at pipeline exit, because the code assumed that the number of available and requested results would always be positive, expecting all the counters to be 0 at the end of a pipeline. This commit switches discardAbortedPipelineResults() and ExecQueryAndProcessResults() to take a softer approach when consuming and draining the results after an error. If there are still piped syncs in the pipeline when it ends, we now attempt to consume them before leaving the pipeline mode. Alexander has been able to reach two assertion failures through his testing. While investigating more this issue, I have bumped into two more. Most of these cases are covered by the regression tests added in this commit, plus some cases with mixes of pipelines, deferred errors and results fetched. Some of the tests discussed (like the backend termination one) could not be included in this commit but have been tested manually. Another test scenario discussed involved the injection of an error state in the backend, that was able to trick libpq internally and put its queue out of sync. This scenario is not going to happen in practice, but if we were to do something about it we would need to make libpq understand that it needs to fail in some cases but not block. Reported-by: Alexander Lakhin <[email protected]> Author: Michael Paquier <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 18 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1e9bc4074beb7678bc2fed1a104929f8e9da1615 Modified Files -------------- src/bin/psql/common.c | 76 +++++++++++++---- src/test/regress/expected/psql_pipeline.out | 124 ++++++++++++++++++++++++++++ src/test/regress/sql/psql_pipeline.sql | 63 ++++++++++++++ 3 files changed, 245 insertions(+), 18 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-06-02 23:58 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-06-02 23:58 pgsql: psql: Fix issues with deferred errors in pipelines Michael Paquier <[email protected]> 2026-06-02 23:58 pgsql: psql: Fix issues with deferred errors in pipelines Michael Paquier <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox