From c52d7931e95cc24804f9aac4c9bf3a388c7e461f Mon Sep 17 00:00:00 2001 From: Kyotaro Horiguchi Date: Mon, 19 Jul 2021 10:58:01 +0900 Subject: [PATCH v1] Remove possible instability of new replication slot test code The last fix for the same left another possible timing unstability between actual segment removal and the invalidation log. Make it steady by waiting for checkpoint-ending log, which is issued after the segment removal. --- src/test/recovery/t/019_replslot_limit.pl | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/src/test/recovery/t/019_replslot_limit.pl b/src/test/recovery/t/019_replslot_limit.pl index 026da02ff1..a5d8140807 100644 --- a/src/test/recovery/t/019_replslot_limit.pl +++ b/src/test/recovery/t/019_replslot_limit.pl @@ -11,7 +11,7 @@ use TestLib; use PostgresNode; use File::Path qw(rmtree); -use Test::More tests => $TestLib::windows_os ? 15 : 19; +use Test::More tests => $TestLib::windows_os ? 16 : 20; use Time::HiRes qw(usleep); $ENV{PGDATABASE} = 'postgres'; @@ -201,6 +201,19 @@ $result = $node_primary->safe_psql( is($result, "rep1|f|t|lost|", 'check that the slot became inactive and the state "lost" persists'); +# Make sure the current checkpoint ended +my $checkpoint_ended = 0; +for (my $i = 0; $i < 10000; $i++) +{ + if (find_in_log($node_primary, "checkpoint complete: ", $logstart)) + { + $checkpoint_ended = 1; + last; + } + usleep(100_000); +} +ok($checkpoint_ended, 'make sure checkpoint ended'); + # The invalidated slot shouldn't keep the old-segment horizon back; # see bug #17103: https://postgr.es/m/17103-004130e8f27782c9@postgresql.org # Test for this by creating a new slot and comparing its restart LSN -- 2.27.0