On Wednesday, July 15, 2026 10:16 PM Robert Haas <[email protected]> wrote: > On Wed, Jul 15, 2026 at 4:52 AM Andrey Borodin <x4mmm@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
