git.postgresql.org Git - postgresql.git/commitdiff

git projects / postgresql.git / commitdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: e2d5b3b)
Try to fix pg_walsummary buildfarm failures.
2024年1月11日 20:01:51 +0000 (15:01 -0500)
2024年1月11日 20:01:51 +0000 (15:01 -0500)
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');
This is the main PostgreSQL git repository.
RSS Atom

AltStyle によって変換されたページ (->オリジナル) /