Stabilize and shorten test_checksums/013_rewind test

Hi,

I encountered two problems with the test_checksums/013_rewind test:

1. It takes ~45 seconds to finish on my machine and it seems timing
doesn't depend the machine it runs on. It is always last finishing
tests on my machine and I need to wait ~30 seconds after all other
tests are done. Some numbers:

Local: 013_rewind -> 45s | 027_stream_regress -> 24s

Windows CI: 013_rewind -> 33s | 027_stream_regress -> 150s

2. The "8 - last common checkpoint is a shutdown checkpoint" test is
flaky. This test fails ~1/10 of the runs on my machine without any
external effort. Error message:

[11:31:29.021](0.007s) not ok 8 - last common checkpoint is a shutdown
checkpoint
[11:31:29.022](0.001s) # Failed test 'last common checkpoint is a
shutdown checkpoint'
# at /home/nbyavuz/Desktop/projects/postgres/src/test/modules/test_checksums/t/013_rewind.pl
line 161.
[11:31:29.022](0.000s) # ''
# doesn't match '(?^:CHECKPOINT_SHUTDOWN)'

I also saw same error on the CI [1]https://github.com/postgres/postgres/actions/runs/35096253076/job/104794579050#step:13:499.

----------------------------------------

I spent some time fixing these problems with the help of an LLM.

Problem #1:

We wait for the primary's insert LSN in three places, but the primary
might be idle and not have sent it yet:

1.1:

$node_a->backup('backup');
my $node_b = PostgreSQL::Test::Cluster->new('node_b');
$node_b->init_from_backup($node_a, 'backup', has_streaming => 1);
$node_b->start;

$node_a->wait_for_catchup($node_b, 'replay', $node_a->lsn('insert'));
test_checksum_state($node_a, 'off');
test_checksum_state($node_b, 'off');

backup() already flushes the LSN, we can wait for the flush LSN here.

1.2

$node_a->safe_psql('postgres', "CHECKPOINT;");
$node_a->wait_for_catchup($node_b, 'replay', $node_a->lsn('insert'));

Since there is already a CHECKPOINT, the changes should be flushed. We
can wait for the flush LSN.

1.3

# Start the rewound node as a standby of the new primary. Replay runs
# through the pre-enable WAL stretch and the online enable.
#
# The rewind replaced the configuration files with those of the new
# primary, so put the port back.
...
$node_a->set_standby_mode;
$node_a->start;

$node_b->wait_for_catchup($node_a, 'replay', $node_b->lsn('insert'));
test_checksum_state($node_a, 'on');

We can use pg_switch_wal() function to make sure changes are flushed
and then we can wait for the flush LSN.

These 3 changes reduces test time from ~45s to ~3s on my local environment.

----------------------------------------

Problem #2

($stdout, $stderr) = run_command(
[
'pg_waldump',
'-p' => $node_a->data_dir . '/pg_wal',
'-t' => 1,
'-s' => $shutdown_ckpt,
'-n' => 1,
]);
like($stdout, qr/CHECKPOINT_SHUTDOWN/,
'last common checkpoint is a shutdown checkpoint');

We don't specifiy which WAL file that pg_waldump() will use, then
pg_waldump select first WAL data available in the directory. Then, it
might select a WAL file whose header is not initialized yet (a
preallocated WAL file). So, when pg_waldump tries to get segment_size
from this file it reads 0 and fails. I run pg_waldump on the failed
test artifacts and I get this error; which I think confirms the
problem:

$ pg_waldump -p
testrun/test_checksums/013_rewind/data/t_013_rewind_node_a_data/pgdata/pg_wal/
pg_waldump: error: invalid WAL segment size in WAL file
"000000020000000000000005" (0 bytes)
pg_waldump: detail: The WAL segment size must be a power of two
between 1 MB and 1 GB.

This problem is solved by specifying the WAL file.

----------------------------------------

Two patchs are attached, 0001 for the problem #1 and 0002 for the problem #2.

[1]: https://github.com/postgres/postgres/actions/runs/35096253076/job/104794579050#step:13:499

--
Regards,
Nazir Bilal Yavuz
Microsoft