RE: walsummarizer can get stuck when switching timelines

On Wednesday, July 15, 2026 10:16 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jul 15, 2026 at 4:52 AM Andrey Borodin <x4mmm(at)yandex-
> team.ru> wrote:
> > I can reproduce it locally by adding an extra WAL switch on node1
> > before promoting node2. It can probably be made deterministic either
> > by polling pg_stat_archiver before relying on the segment (as
> > 025_stuck_on_old_timeline.pl does) or by setting archive_mode=always
> > on
> > node2 (I would expect it to be a bit faster).
>
> archive_mode=always seems like the correct fix. Here's v2.

While reading the WAL summarization code, I ran the new 003_tli_switch test and
noticed it takes about 14 seconds to finish on my machine, which prompted me to
debug it a bit. The delay comes from the 10-second wait in the error recovery
path (WAIT_EVENT_WAL_SUMMARIZER_ERROR) in WalSummarizerMain, where it retries
after failing to read an unarchived WAL file.

I was wondering whether it's worth improving this. We could enable summarize_wal
on node3 only after the WALs on the new timeline become readable on node3, which
would eliminate the retry and reduce the test time by about 10 seconds on my
machine. However, if the intention is to exercise the retry logic in
WalSummarizerMain as well, the current test is fine as is. Just sharing this in
case the test time wasn't intentional.

Apart from the test, the fix looks good to me.

Best Regards,
Hou zj