Re: Incremental backup can use a summary past a timeline switch

Hi Ayush,

On Thu, Oct 22, 2026 at 11:29 PM Ayush Tiwari
<ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
> My worry was that a truncation in that summary could drop block
> references from the new timeline when we merge it. We'd then miss
> those blocks in the incremental backup and take stale ones from the
> earlier backup instead.

I could reproduce it. The setup is in the attached script: the standby
pauses at recovery_target_lsn = the redo LSN of a checkpoint, with
recovery_target_inclusive = false. Before that point the primary
updates rows 5..8 of an 8-block table, which the standby replays.
After it, the primary runs DELETE + VACUUM, truncating the table to 4
blocks, and checkpoints. The standby summarizes that WAL but never
replays it, and is then promoted.

The timeline 1 summary that starts at the switch point holds "limit 4"
for the table. It gets merged and drops blocks 4..11, the INCREMENTAL
file ends up with 0 blocks and truncation_block_length 12, and after
pg_combinebackup rows 5..8 come back with their pre-update contents.
pg_verifybackup reports both backups as valid.

On master with Fujii's v1-0001 from the #19774 thread that happened in
5 of 5 runs on tmpfs and 5 of 5 on btrfs. Without v1-0001 it was 5 of
5 on btrfs and 0 of 5 on tmpfs, where readdir happens to merge the
old-timeline summary first. With your v1: 0 of 10, with and without
v1-0001. Your patch applies cleanly either way, and make check,
pg_walsummary, pg_combinebackup and the recovery suite pass with it.

One note for anyone running the script: reading the table on the
promoted server before the backup can hide the loss, because with
data checksums the hint-bit FPIs mark those blocks again on the new
timeline. The script also keeps the target off page boundaries, which
hit a different error [1].

[1] https://postgr.es/m/CAK49S1A28oFELOo++Vo2Nr_Jh0KQcv5GwUs7dXNLDW7qLiZiXw@mail.gmail.com

Regards,
Manu