On Thu, Jul 30, 2026 at 1:58 PM Masahiko Sawada <[email protected]> wrote: > > On Thu, Jul 30, 2026 at 2:00 AM Amit Kapila <[email protected]> wrote: > > > > On Thu, Jul 30, 2026 at 12:37 PM Masahiko Sawada <[email protected]> > > wrote: > > > > > > Thank you for testing it. It seems to be reproducible also on CI, and > > > I believe I've fixed the issue. > > > > > > I've attached the patch. Please review it. > > > > > > > LGTM. > > Thank you for reviewing the patch. Pushed. > > ... but some buildfarm members are unhappy. I'm working on it. >
I've reproduced the issue on local and confirmed the root cause; two background psql sessions in the TAP test run with ON_ERROR_STOP=1 and got canceled by pg_cancel_backend(), so psql exited as soon as the cancelation error arrived. I've attached the patch that fixes the problem. I'm waiting for CI to check if the tests still pass on other environments. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
From 13524f3c11621442fbe9e5bb7e3105ccc2afd8ff Mon Sep 17 00:00:00 2001 From: Masahiko Sawada <[email protected]> Date: Thu, 30 Jul 2026 14:32:15 -0700 Subject: [PATCH] Fix background psql session cleanup in 051_effective_wal_level.pl. Two background psql sessions in this test have their slot creation canceled by pg_cancel_backend(). Both ran with the default ON_ERROR_STOP=1 and ended their script with \q, so psql exited as soon as the cancellation error arrived. BackgroundPsql::quit() then appends another \q to the session, which fails against the already-closed pipe. Run both sessions with on_error_stop => 0 and drop the trailing \q, so that psql stays at the prompt after reporting the error and quit(). Reviewed-by: Discussion: https://postgr.es/m/cad21aoczy1fkygfkvhgwgixpatukd23fslndcl4m9bwfjdx...@mail.gmail.com Backpatch-through: 19 --- src/test/recovery/t/051_effective_wal_level.pl | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/test/recovery/t/051_effective_wal_level.pl b/src/test/recovery/t/051_effective_wal_level.pl index 02f750097bd..11bf4cb6134 100644 --- a/src/test/recovery/t/051_effective_wal_level.pl +++ b/src/test/recovery/t/051_effective_wal_level.pl @@ -438,7 +438,8 @@ select pg_drop_replication_slot('slot_2'); # Start a psql session to test the case where the activation process is # interrupted. - $psql_create_slot = $primary->background_psql('postgres'); + $psql_create_slot = + $primary->background_psql('postgres', on_error_stop => 0); # Start the logical decoding activation process upon creating the logical # slot, but it will wait due to the injection point. @@ -448,7 +449,6 @@ select pg_drop_replication_slot('slot_2'); select injection_points_set_local(); select injection_points_attach('logical-decoding-activation', 'wait'); select pg_create_logical_replication_slot('slot_canceled', 'pgoutput'); -\q )); $primary->wait_for_event('client backend', 'logical-decoding-activation'); @@ -470,7 +470,8 @@ select pg_cancel_backend(pid) from pg_stat_activity where query ~ 'slot_canceled $psql_create_slot->quit; # Test concurrent activation processes run and one is interrupted. - $psql_create_slot = $primary->background_psql('postgres'); + $psql_create_slot = + $primary->background_psql('postgres', on_error_stop => 0); # Start a psql session and stops in the middle of the activation # process. @@ -480,7 +481,6 @@ select pg_cancel_backend(pid) from pg_stat_activity where query ~ 'slot_canceled select injection_points_set_local(); select injection_points_attach('logical-decoding-activation', 'wait'); select pg_create_logical_replication_slot('slot_canceled2', 'pgoutput'); -\q )); $primary->wait_for_event('client backend', 'logical-decoding-activation'); note("injection_point 'logical-decoding-activation' is reached"); -- 2.55.0
