Re: Incremental backup accepts a prior backup that extends past a timeline switch

On Mon, Nov 2, 2026 at 2:51 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> Attached is a revised version with these changes:
>
> - Check the timeline switch point before the new backup's start LSN,
> so the error directly reports the history mismatch.

Hi Fujii-san,

Thanks for the revised version, it reads better with the check before the
start-LSN one.

I tested v2 on master: it builds without warnings, and the pg_combinebackup
and pg_basebackup TAP tests pass. My original async-failover reproduction
(a full backup on the old primary whose WAL range ends after the standby's
switch point) is now rejected with "manifest requires WAL from final
timeline 1 ending at 0/05631BC0, but this server switched timelines at
0/04001338". Incrementals across a promotion that should keep working still
combine and restore with data matching the live server: a full on the old
primary before the switch, and a full on the standby before promotion.

For the back-branches: v2 applies cleanly to REL_18_STABLE. On
REL_17_STABLE the code and doc changes apply, and only the hunk for the
008_promote test conflicts, since the option style differs there. With the
code change on 17, the same reproduction is rejected, the cases above still
pass, and the TAP tests pass.

One small observation about the test: without the code change, the new case
in the 008_promote test still fails, with "WAL summaries are required on
timeline 2 ... incomplete", so it detects the problem through the error
message rather than by the backup succeeding. That seems fine to me, just
mentioning it.

v2 looks good to me.

Regards,
Sai Pranav

On Mon, Nov 02, 2026 02:51 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Sat, Oct 24, 2026 at 5:39 AM Raja Sai pranav
> <rajasaipranav0(at)gmail(dot)com> wrote:
> > The attached patch adds the missing check: if the prior backup's final
> > timeline has an end in this server's history, the prior backup's WAL
> range
> > must not end after it.
>
> Thanks for the report and patch!
> Attached is a revised version with these changes:
>
> - Check the timeline switch point before the new backup's start LSN,
> so the error directly reports the history mismatch.
> - Extend 008_promote.pl rather than adding a separate test.
> - Document the timeline requirement for incremental backup.
>
> Thought?
>
> Regards,
>
> --
> Fujii Masao
>