Re: walsummarizer can get stuck when switching timelines

On Thu, Jul 16, 2026 at 2:05 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> Of course I'd like that fix committed too :) But that's not why I'm raising it here.
>
> +# The reason for the problem is that when a new primary is promoted, the
> +# partial file that ends the old timeline is renamed, giving it a ".partial"
> +# suffix, and is not archived. That's not a problem for recovery, because
> +# the bytes that appear at the start of that segment will be copied into the
> +# first segment on the new timeline, and recovery will read them from there
> +# and work just fine.
>
> That only holds when the new timeline's segment is already available. If it isn't,
> XLogFileReadAnyTLI() falls back to the ancestor's segment and, past the switch point,
> hands recovery the old timeline's divergent WAL. It's the mirror, on the recovery
> side, of what your patch fixes for the summarizer.
>
> I'm not asking you to fix XLogFileReadAnyTLI() here. I just don't think the new
> comment should claim recovery is unaffected.

In the scenario tested by this test case, recovery works fine. Without
the patch, node3 follows the timeline switch from TLI 1 to TLI 2 and
continues recovery thereafter without a problem. Only WAL
summarization gets stuck. Maybe I need to go read your thread to
figure out why you think these are the same problem, but based on what
the test case does, I feel like they are different problems.

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