On Wed, Aug 12, 2026 at 12:06 PM Hayato Kuroda (Fujitsu) <[email protected]> wrote: > Actually the test can pass without increasing the max_wal_size. Ultimately, > we do > not have to set both min_wal_size and max_wal_size: we enforce the CHECKPOINT > here. My fresh brain feels that such unnecessary settings can be avoided, done > in v2.
Thanks for updating the patch! The test changes look good to me. I also updated the commit message and adjusted the comment for the new test. Attached is v3. Barring any objections, I'm thinking to commit it. Regards, -- Fujii Masao
From b82a2656d4009fc986f01d6f353bdef5751d54eb Mon Sep 17 00:00:00 2001 From: Hayato Kuroda <[email protected]> Date: Fri, 7 Aug 2026 15:35:31 +0900 Subject: [PATCH v3] Stabilize 019_replslot_limit The test assumed that advancing WAL would lead to a checkpoint that invalidates the obsolete replication slot. If a checkpoint that started before the WAL switch completes first, the following checkpoint can be skipped as idle, so the expected walsender termination is not logged. Force a CHECKPOINT in a background psql session after advancing WAL, so the slot invalidation is exercised deterministically. This has been observed on buildfarm members alligator and partridge: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=alligator&dt=2024-12-13%2001%3A24%3A58 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=partridge&dt=2026-08-06%2018%3A00%3A11 Backpatch to all supported versions. Reported-by: Alexander Lakhin <[email protected]> Author: Hayato Kuroda <[email protected]> Reviewed-by: Alexander Lakhin <[email protected]> Reviewed-by: Fujii Masao <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14 --- src/test/recovery/t/019_replslot_limit.pl | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/test/recovery/t/019_replslot_limit.pl b/src/test/recovery/t/019_replslot_limit.pl index 1eec98f2c9e..e78b548b213 100644 --- a/src/test/recovery/t/019_replslot_limit.pl +++ b/src/test/recovery/t/019_replslot_limit.pl @@ -314,8 +314,6 @@ my $node_primary3 = get_new_node('primary3'); $node_primary3->init(allows_streaming => 1, extra => ['--wal-segsize=1']); $node_primary3->append_conf( 'postgresql.conf', qq( - min_wal_size = 2MB - max_wal_size = 2MB log_checkpoints = yes max_slot_wal_keep_size = 1MB )); @@ -345,6 +343,16 @@ $logstart = get_log_size($node_primary3); kill 'STOP', $senderpid, $receiverpid; advance_wal($node_primary3, 2); +# Run CHECKPOINT in the background. It is expected to reach slot +# invalidation, signal the stopped walsender, and then wait until the +# walsender releases the slot. +my $checkpoint = $node_primary3->background_psql('postgres'); +$checkpoint->query_until( + qr/starting_checkpoint/, q( + \echo starting_checkpoint + CHECKPOINT; +)); + my $max_attempts = $TestLib::timeout_default; while ($max_attempts-- >= 0) { @@ -366,6 +374,7 @@ $node_primary3->poll_query_until('postgres', "SELECT wal_status FROM pg_replication_slots WHERE slot_name = 'rep3'", "lost") or die "timed out waiting for slot to be lost"; +$checkpoint->quit; $max_attempts = $TestLib::timeout_default; while ($max_attempts-- >= 0) -- 2.55.0
v3-0001-Stabilize-019_replslot_limit.patch
Description: Binary data
From 1b2b08dd2599ec187a03f695ae45d6290eeaf9c6 Mon Sep 17 00:00:00 2001 From: Hayato Kuroda <[email protected]> Date: Fri, 7 Aug 2026 15:35:31 +0900 Subject: [PATCH v3] Stabilize 019_replslot_limit The test assumed that advancing WAL would lead to a checkpoint that invalidates the obsolete replication slot. If a checkpoint that started before the WAL switch completes first, the following checkpoint can be skipped as idle, so the expected walsender termination is not logged. Force a CHECKPOINT in a background psql session after advancing WAL, so the slot invalidation is exercised deterministically. This has been observed on buildfarm members alligator and partridge: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=alligator&dt=2024-12-13%2001%3A24%3A58 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=partridge&dt=2026-08-06%2018%3A00%3A11 Backpatch to all supported versions. Reported-by: Alexander Lakhin <[email protected]> Author: Hayato Kuroda <[email protected]> Reviewed-by: Alexander Lakhin <[email protected]> Reviewed-by: Fujii Masao <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14 --- src/test/recovery/t/019_replslot_limit.pl | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/test/recovery/t/019_replslot_limit.pl b/src/test/recovery/t/019_replslot_limit.pl index 4ec1a9ab33a..ee5a08f57c0 100644 --- a/src/test/recovery/t/019_replslot_limit.pl +++ b/src/test/recovery/t/019_replslot_limit.pl @@ -309,8 +309,6 @@ my $node_primary3 = PostgreSQL::Test::Cluster->new('primary3'); $node_primary3->init(allows_streaming => 1, extra => ['--wal-segsize=1']); $node_primary3->append_conf( 'postgresql.conf', qq( - min_wal_size = 2MB - max_wal_size = 2MB log_checkpoints = yes max_slot_wal_keep_size = 1MB )); @@ -378,6 +376,16 @@ $logstart = get_log_size($node_primary3); kill 'STOP', $senderpid, $receiverpid; advance_wal($node_primary3, 2); +# Run CHECKPOINT in the background. It is expected to reach slot +# invalidation, signal the stopped walsender, and then wait until the +# walsender releases the slot. +my $checkpoint = $node_primary3->background_psql('postgres'); +$checkpoint->query_until( + qr/starting_checkpoint/, q( + \echo starting_checkpoint + CHECKPOINT; +)); + my $max_attempts = $PostgreSQL::Test::Utils::timeout_default; while ($max_attempts-- >= 0) { @@ -399,6 +407,7 @@ $node_primary3->poll_query_until('postgres', "SELECT wal_status FROM pg_replication_slots WHERE slot_name = 'rep3'", "lost") or die "timed out waiting for slot to be lost"; +$checkpoint->quit; $max_attempts = $PostgreSQL::Test::Utils::timeout_default; while ($max_attempts-- >= 0) -- 2.55.0
