Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit a7097ca

Browse files
committed
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.
1 parent e2d5b3b commit a7097ca

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

src/bin/pg_walsummary/t/002_blocks.pl

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -78,10 +78,10 @@
7878
split(m@/@, $end_lsn);
7979
ok(-f $filename, "WAL summary file exists");
8080

81-
# Run pg_walsummary on it. We expect block 0 to be modified, but block 1
82-
# to be unmodified, so the output should say block 0, not block 0..1 or
83-
# similar.
84-
my ($stdout, $stderr) = run_command([ 'pg_walsummary', $filename ]);
81+
# Run pg_walsummary on it. We expect block 0 to be modified, but depending
82+
# on where the new tuple ends up, block 1 might also be modified, so we
83+
# pass -i to pg_walsummary to make sure we don't end up with a 0..1 range.
84+
my ($stdout, $stderr) = run_command([ 'pg_walsummary', '-i', $filename ]);
8585
like($stdout, qr/FORK main: block 0$/m, "stdout shows block 0 modified");
8686
is($stderr, '', 'stderr is empty');
8787

0 commit comments

Comments
 (0)