On Thu, 16 Jul 2026 at 14:46, Thom Brown <[email protected]> wrote: > > On Thu, 16 Jul 2026 at 14:45, Robert Haas <[email protected]> wrote: > > > > On Thu, Jul 16, 2026 at 8:59 AM Thom Brown <[email protected]> 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
