rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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.
This commit is contained in:
Robert Haas 2024-01-11 15:01:51 -05:00
parent e2d5b3b9b6
commit a7097ca630
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/bin/pg_walsummary/t/002_blocks.pl
View File

@ -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');