Re: walsummarizer can get stuck when switching timelines

On Thu, 16 Jul 2026 at 13:39, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Jul 16, 2026 at 7:46 AM Thom Brown <thom(at)linux(dot)com> wrote:
> > +# Cause the partial segment to get archived on the *new* timeline.
> > +#
> > +# In more detail: the WAL segment that contains the current insert
> > LSN exists on
> > +# timeline 1, but since all we did is CREATE TABLE dummy (), it
> > wasn't full. We're
> > +# now running on timeline 2, and pg_switch_wal() fills up the rest of
> > the segment.
> > +# So the full segment should get archived on timeline 2, but not on timeline 1.
> > +# We do a CHECKPOINT here to make sure that the summarizer tries to progress.
> > +$node2->safe_psql('postgres', <<EOM);
> > +SELECT pg_switch_wal();
> > +CHECKPOINT;
> >
> > Wouldn't we want the checkpoint's redo record to make it into the
> > archived segment *before* switching wal?
>
> I don't think so, but maybe you want to explain why you think so.

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. I guess it works if the
checkpoint triggered by promotion always happens before
pg_switch_wal(), but it seems like it could just as well happen
afterwrds. If so, that would make the test depend on timing.

I could be misunderstanding the intended purpose here, though. It just
looked to me like CHECKPOINT; SELECT pg_switch_wal(); would be
deterministic, whereas the current ordering appears to rely on the
promotion checkpoint winning the race.

Or maybe I need to rethink after some caffeine.

Thom