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