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.

diff --git a/src/bin/pg_walsummary/t/002_blocks.pl b/src/bin/pg_walsummary/t/002_blocks.pl
index 170976f9e2deb38d50201e09a6b321fd1aa050ca..d473471bc7ee70dd1595d18f4fdfc081a1d1587c 100644 (file)
--- 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');