database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-11 20:28:21 +03:00
Code Activity

Try to fix pg_walsummary buildfarm failures.

Browse Source 
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
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');