mirror of
https://github.com/postgres/postgres.git
synced 2025-04-25 21:42:33 +03:00
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:
parent
e2d5b3b9b6
commit
a7097ca630
@ -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');
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user