Re: walsummarizer can get stuck when switching timelines

On Tue, Jul 14, 2026 at 8:41 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> It seems correct to me: we stop at switch_lsn, so we
> only read the pre-switch bytes both timelines share. But it might be worth a
> test.

I don't think I'm sufficiently motivated to want to write a TAP test
for two timeline switches in the same segment. If you want to try it,
feel free. We can add that in a later commit; it doesn't need to be
part of this patch.

> Second, in the fallback path WALRead reopens the segment on every page,
> because the requested tli never matches seg.ws_tli once
> summarizer_wal_segment_open() has moved to a descendant. These open/close
> might be an exatra overhead?

I can believe this might be the case, and I'll look into fixing it. I
don't think it makes any practical difference because segments
containing timeline switches are rare and only contain so many blocks,
and opening and closing files is not that expensive. But it makes
sense to get this right.

> I think, there's a symmetric bug on the recovery side with the same root cause.
> Your patch makes the summarizer fall forward to a descendant timeline, which
> looks safe. XLogFileReadAnyTLI() does the opposite: when the switch-point segment
> is missing on the target timeline, it falls back to an ancestor and reads the
> same segno. But that segment holds divergent data continuing old timeline!
> Recovery applies it silently and then can't reach the intended timeline.

I think this is only a problem if somebody reads past the switchpoint.
In any case, this thread is not about fixing bugs in
XLogFileReadAnyTLI() or its callers.

--
Robert Haas
EDB: http://www.enterprisedb.com