Re: walsummarizer can get stuck when switching timelines

On Thu, 16 Jul 2026 at 14:46, Thom Brown <thom(at)linux(dot)com> wrote:
>
> On Thu, 16 Jul 2026 at 14:45, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > On Thu, Jul 16, 2026 at 8:59 AM Thom Brown <thom(at)linux(dot)com> wrote:
> > > Well if we run pg_switch_wal(), we're effectively closing the current
> > > segment. CHECKPOINT then emits its WAL after the switch. If the
> > > summarizer needs a CHECKPOINT_REDO record in the segment being
> > > archived, it would already be too late.
> >
> > OK, I think this is where we're seeing things differently. The
> > summarizer doesn't need a CHECKPOINT_REDO record in the segment being
> > archived. Rather, we need a CHECKPOINT_REDO record somewhere after the
> > WAL that we want summarized. In this case, the WAL we want summarized
> > is generated by the pg_switch_wal() call.
>
> Ah, gotcha. Sorry for the noise.

Another question; I'm seeing this in 003_tli_switch_node3.log:

2026-07-17 16:57:50.525 BST walsummarizer[714073] DEBUG: timeline 1
became historic, can read up to 0/0301E118
2026-07-17 16:57:50.525 BST walsummarizer[714073] ERROR: requested
WAL segment pg_wal/000000010000000000000003 has already been removed
2026-07-17 16:58:00.533 BST walsummarizer[714073] DEBUG: switch point
from TLI 1 to TLI 2 is at 0/0301E118
2026-07-17 16:58:00.534 BST walsummarizer[714073] DEBUG: summarized
WAL on TLI 1 from 0/02000028 to 0/0301E118
2026-07-17 16:58:00.534 BST walsummarizer[714073] DEBUG: summarized
WAL on TLI 2 from 0/0301E118 to 0/0301E150

It's erroring out, but shouldn't it check for 000000020000000000000003
before doing so? It wasn't removed, just renamed.

Thom