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

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Subject: Re: Incremental backup can use a summary past a timeline switch
Date: 2026-10-23 01:59:36
Message-ID: C19203C5-3720-4A4B-A0A0-F5B648C60DE0@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Oct 23, 2026, at 01:59, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
>
> Hi,
>
> Moving the corner case I mentioned in the BUG #19774 thread [1] here,
> as Fujii-san suggested.
>
> IIUC, a standby can summarize WAL ahead of replay. So if recovery
> ends at the start of one of those summaries, we could still have an
> old-timeline summary for WAL we didn't replay. FilterWalSummaries()
> seems to keep that file, unlike GetWalSummaries().
>
> 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.
>
> The attached patch makes the >= / <= checks match GetWalSummaries().
>
> I have a TAP reproducer, but it's fairly involved, so I've kept it out
> of the patch for now. Happy to share it if it's useful.
>
> [1] https://postgr.es/m/19774-8a1cbfd1774fcd0c@postgresql.org
>
> Regards,
> Ayush
> <v1-0001-Use-half-open-LSN-ranges-in-FilterWalSummaries.patch>

I think the fix is correct. FilterWalSummaries()’s header comment already correctly describes the behavior with “after” and “before”, but the code was wrong.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Henson Choi 2026-10-23 01:58:29 Re: [DEPARSE] Operators on ROW() constructors read back as row comparisons