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
