At Thu, 29 Jul 2021 16:20:38 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> So it seems to me we need to explicitly prevent unexpected checkpoints
> from happening maybe by enlarging max_wal_size temporily.
>
> I'll going that way.
I ended up with the attached. It causes a checkpoint reliably exactly
at the aimed timing without.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From faca25782953d208bcf7b1e4ea0d62a40be3c7f1 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Date: Thu, 29 Jul 2021 16:36:32 +0900
Subject: [PATCH] Make slot test more stable
The slot test still instable in the case where test script runs
relatively slower than checkpointing. Remove the instability by
causing a checkpoint exactly at the aimed timing.
---
src/test/recovery/t/019_replslot_limit.pl | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/test/recovery/t/019_replslot_limit.pl b/src/test/recovery/t/019_replslot_limit.pl
index 54ddcef2bb..ee4801b49c 100644
--- a/src/test/recovery/t/019_replslot_limit.pl
+++ b/src/test/recovery/t/019_replslot_limit.pl
@@ -173,10 +173,20 @@ ok( !find_in_log(
"requested WAL segment [0-9A-F]+ has already been removed"),
'check that required WAL segments are still available');
-# Advance WAL again, the slot loses the oldest segment.
+# prevent checkpoints from occurring while advancing WAL segments
+$node_primary->safe_psql('postgres', "CHECKPOINT;");
+$node_primary->safe_psql('postgres',
+ "ALTER SYSTEM SET max_wal_size='40MB'; SELECT pg_reload_conf()");
+
+# Advance WAL again, the slot loses the oldest segment by the coming checkpoint.
my $logstart = get_log_size($node_primary);
advance_wal($node_primary, 7);
+# Cause a checkpoint
+$node_primary->safe_psql('postgres',
+ 'ALTER SYSTEM RESET max_wal_size; SELECT pg_reload_conf()');
+$node_primary->safe_psql('postgres', "CHECKPOINT;");
+
# wait until the WARNING is issued
my $invalidated = 0;
for (my $i = 0; $i < 10000; $i++)
--
2.27.0