Hi,
I hit the same assertion independently earlier and can confirm Manu's
analysis.
Before promotion, with Fujii's steps on master:
replay 0/03001B08
receive 0/03001D98
summarized 0/03001CB0
which matches the numbers in Manu's mail. The size of the gap between
replay and receive doesn't matter: with ~20MB of streamed WAL past an
arbitrary recovery_target_lsn (recovery_target_inclusive = true) the
summarizer is ~20MB ahead and the crash is the same.
With cassert disabled, I don't see any adverse effects either: summaries
on TLI 2 start at the switch point, and an incremental backup across the
promotion works.
With v1 applied on master, the same scenarios pass with cassert and the
new test passes; with the walsummarizer.c hunk reverted, the test fails
with the TRAP. pg_walsummary and pg_combinebackup TAP suites pass.
A couple of minor comments on v1:
1. The comment in summarizer_read_local_xlog_page() about read_upto
moving backwards says the next iteration will "likely conclude that
we've reached end of WAL". It might be worth mentioning there that
SummarizeWAL() then reports no progress, so the link between the two
places is visible from both sides.
2. In the test, the summarizer PID check and the log check both detect
the same thing, a restart after the crash. Without the fix neither
is reached anyway: pg_ctl promote fails once the postmaster
reinitializes, and the test dies without a plan. I think one of the
two checks would be sufficient.
Separately, while looking at this I found a related but different
problem: if the switch point falls exactly on a page or segment
boundary, the first summary on the new timeline starts after the page
header, and incremental backups on top of any pre-promotion backup fail
permanently with "WAL summaries are required on timeline 2 from
0/04000000 ...". v1 doesn't change that, and it isn't expected to. I'll
look into it
more closely and then maybe start a separate thread with a reproducer.
--
Daria Lepikhova
