| 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/
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Henson Choi | 2026-10-23 01:58:29 | Re: [DEPARSE] Operators on ROW() constructors read back as row comparisons |