Re: pg_walinspect: add functions to locate and list WAL by time and LSN

Hi Chao,

Thanks for v3. Moving to outer anchors with the fallback to the current WAL
position addresses my concern with v2, and I appreciate the new tests
covering both the empty-window case and the DELETE scenario.

v3 applies cleanly to master (f884f359f5a) and builds without warnings.
Locally, the regression tests and both TAP tests pass, and so does my
earlier reproducer. The returned range now brackets the DELETE:

start_lsn | end_lsn | delete_lsn
------------+------------+------------
0/017F0220 | 0/017F02E0 | 0/017F0280

However, CFBot's macOS - Meson job fails on v3 (
https://github.com/postgres/postgres-cfbot/actions/runs/37738280802/job/113183259446)
in 001_timeline.pl, during the archive_mode=0 pass:

ERROR: WAL segment needed for the requested range is missing
DETAIL: Segment 4 is not present in pg_wal.
... FROM pg_get_wal_files('0/04001790', pg_current_wal_lsn())

The standby's server log from that run points to a race in the test rather
than a bug in pg_get_wal_files():

06:52:52.657 received promote request
06:52:52.701 checkpoint starting: force
06:52:52.938 checkpoint complete: ... 0 WAL file(s) added, 0 removed, 2
recycled
06:52:52.972 ERROR: WAL segment needed for the requested range is
missing

The checkpoint forced by the promotion recycled two WAL segments, and since
segment 4, which holds start_lsn, was gone 34 ms later, it must have been
one of them. On a faster machine the query runs before that checkpoint
completes, which would explain why the test passes locally.

Keeping that WAL on the standby makes the test deterministic. I confirmed
this locally with a copy of the test that forces a CHECKPOINT right after
promote(): it fails every time with the same "Segment 4 is not present"
error, and passes once the standby has wal_keep_size set:

$standby->init_from_backup($primary, $backup_name, has_streaming => 1);
$standby->append_conf('postgresql.conf', "wal_keep_size = '64MB'");

src/test/recovery/t/004_timeline_switch.pl uses wal_keep_size the same way.

One small question on 0001. For a point lookup at the current LSN on a
segment boundary, v3 now returns the preceding segment, which makes sense
given that the next file may not exist yet. pg_walfile_name(), though, maps
the same LSN to the next segment (it uses XLByteToSeg). So at that one LSN
the two functions name different files. I'm fine with the choice, since the
docs explain it, but it may be worth a sentence noting the difference from
pg_walfile_name().

Regards,
Surya Poondla