From a7097ca630a25dd2248229f21ebce4968d85d10a Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Thu, 11 Jan 2024 15:01:51 -0500 Subject: [PATCH] Try to fix pg_walsummary buildfarm failures. Apparently the new tuple isn't guaranteed to end up at the end of the relation, so make the test not depend on that happening. --- src/bin/pg_walsummary/t/002_blocks.pl | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/bin/pg_walsummary/t/002_blocks.pl b/src/bin/pg_walsummary/t/002_blocks.pl index 170976f9e2..d473471bc7 100644 --- a/src/bin/pg_walsummary/t/002_blocks.pl +++ b/src/bin/pg_walsummary/t/002_blocks.pl @@ -78,10 +78,10 @@ my $filename = sprintf "%s/pg_wal/summaries/%08s%08s%08s%08s%08s.summary", split(m@/@, $end_lsn); ok(-f $filename, "WAL summary file exists"); -# Run pg_walsummary on it. We expect block 0 to be modified, but block 1 -# to be unmodified, so the output should say block 0, not block 0..1 or -# similar. -my ($stdout, $stderr) = run_command([ 'pg_walsummary', $filename ]); +# Run pg_walsummary on it. We expect block 0 to be modified, but depending +# on where the new tuple ends up, block 1 might also be modified, so we +# pass -i to pg_walsummary to make sure we don't end up with a 0..1 range. +my ($stdout, $stderr) = run_command([ 'pg_walsummary', '-i', $filename ]); like($stdout, qr/FORK main: block 0$/m, "stdout shows block 0 modified"); is($stderr, '', 'stderr is empty');