Re: BUG #19774: Incremental backup loses re-extended blocks when WAL summaries are merged out of LSN order

Hi,

On Wed, 21 Oct 2026 at 13:47, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Tue, Oct 20, 2026 at 8:56 PM PG Bug reporting form
> <noreply(at)postgresql(dot)org> wrote:
> > Sorting
> > the list before the merge fixes this.
>
> Thanks for the report and patch!
>
> Attached is an updated patch that retains your fix, makes minor naming and
> comment changes, and adds a TAP test. The test truncates a table before
> promoting a standby, re-extends it afterward, and verifies the restored data.
> Using different timelines makes the test independent of directory
> enumeration order.

Thanks for the updated patch, it was clear to read.

I think there might be one more corner case here.

IIUC, a standby can summarize WAL ahead of replay. If it gets promoted
right at the start of one of those summaries, FilterWalSummaries()
seems to keep that old-timeline file, and it can tie with the first
new-timeline summary in the sort..

Would it make sense for FilterWalSummaries() to use the same >= / <=
checks as GetWalSummaries()?

The patch looks good to me though.

Regards,
Ayush