From 19a829a3270fb083b3d6ae967cd3b3c02a170a38 Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Thu, 1 Feb 2024 11:46:30 -0500 Subject: [PATCH] Continue my quest to make 002_blocks.pl pass reliably. The latest buildfarm failures show that after the insert, we don't actually wait long enough for WAL summarization to catch up, apparently because the on disk state gets updated before the in-memory state, and so by checking the on disk state to see whether we're caught up and then the in-memory state to see where exactly how far we've progressed, we can, if unlucky, derive an older value of summarized_lsn, messing up the rest of the test. Attempt to fix this by using pg_available_wal_summaries() everywhere in the test and pg_get_wal_summarizer_state() nowhere. Per buildfarm. --- src/bin/pg_walsummary/t/002_blocks.pl | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/src/bin/pg_walsummary/t/002_blocks.pl b/src/bin/pg_walsummary/t/002_blocks.pl index c1303b188c..d4bae3d564 100644 --- a/src/bin/pg_walsummary/t/002_blocks.pl +++ b/src/bin/pg_walsummary/t/002_blocks.pl @@ -46,12 +46,11 @@ SELECT EXISTS ( EOM ok($result, "WAL summarization caught up after insert"); -# Get a list of what summaries we now have. -my $progress = $node1->safe_psql('postgres', <safe_psql('postgres', <poll_query_until('postgres', < '$summarized_lsn' + WHERE end_lsn > '$summarized_lsn' ) EOM ok($result, "got new WAL summary after update"); @@ -73,7 +72,7 @@ ok($result, "got new WAL summary after update"); # Figure out the exact details for the new summary file. my $details = $node1->safe_psql('postgres', < '$summarized_lsn' + WHERE end_lsn > '$summarized_lsn' EOM my @lines = split(/\n/, $details); is(0+@lines, 1, "got exactly one new WAL summary");