Re: BUG #19776: pg_combinebackup ignores the truncation_block_length of an intermediate incremental backup

Hi Ke,

> This problem occurs because in reconstruct_from_incremental_file(),
> pg_combinebackup determines which blocks require reconstruction based only on
> latest_source->truncation_block_length, without considering the
> truncation_block_length of intermediate backups.

Thanks for the report and reproducer.

While walking backward through the backup chain in
reconstruct_from_incremental_file(), we only check
b < latest_source->truncation_block_length when deciding whether an
unassigned block in sourcemap[] can be taken from an earlier backup. If an
intermediate backup truncated the relation and a later backup extended it
again without writing every block in that range (e.g., unwritten pages at
the end of a relation after bulk extension in COPY), those blocks remain
NULL in sourcemap[] and end up being copied from a backup prior to the
truncation.

Attached is a patch that tracks the current truncation_block_length upper
bound as we step backward through the chain and clamps it whenever an
incremental backup has a smaller s->truncation_block_length. Any remaining
unassigned blocks at or above that limit stay NULL in sourcemap[] and are
written as zeroes.

I also extended 011_ib_truncation.pl to cover an intermediate truncation
followed by COPY bulk extension.

Regards,
Rajesh Kumar Thandapani