Re: Assertion failure in WAL summarizer

Hi Shihao,

On Sat, Oct 24, 2026 at 1:04 AM shihao zhong <zhong950419(at)gmail(dot)com>
wrote:
> In my test it goes away if GetLatestLSN() returns the replay position
> during recovery. What do you think?

I think you're right. Your test fails on master in 3 of 3 runs (the
restored copy has 4|0 instead of 4|1) and passes with the attached
0002, which is your idea: during recovery GetLatestLSN() returns the
replay position instead of the walreceiver's flush position
(walsummarizer.c:879-890 on master), so no summary of the old timeline
goes past the switch point. I'll add you as Reported-by to 0002 in
the next version.

0002 also takes away what Fujii's assertion needs, a summarizer ahead
of replay at promotion. On a cassert build of the series without my
v2 fix from upthread, the standby never summarizes past the recovery
target, and the 004 test from v2 times out in its setup waiting for
such a summary (3 of 3). So with 0002 in, v2's change would only be
defensive and its test would need a different setup; without 0002,
v2 is still needed.

0002 does not help with a summary that is already on disk, so 0001
covers that. In repro-C-upgrade.sh.txt the standby runs master until
the promotion and writes a timeline 1 summary across the switch point;
then the server is restarted on the full series (the two patches
below plus 0001 and 0002). The summary is still there, and 0001
refuses the backup (3 of 3) because it records a truncation; summary
entries carry no LSNs, so the part past the switch can't be dropped.
Restarted on master instead, the restore loses data (3 of 3). I did
not build 0002 alone; its backup path is master's.

Two neighboring cases came up this week: Ayush's summary that starts
exactly at the switch point [1], and Sai Pranav's prior backup that
ends past it [2]. 0001 goes on top of their patches as posted and adds
only the check for this case; with both of theirs and none of ours,
your case still loses (measurements.txt, table 1).

Robert, the open question is 0002. The flush branch dates from the
first commit, and I could not find why flushed rather than replayed;
in the original thread you called what summarization should do during
recovery "very much live" [3]. Is anything relying on standby
summaries ahead of replay? If so, 0001 alone covers this by refusing.

Your test name collides with Ayush's t/014; I ran it as t/016.

[1] https://postgr.es/m/CAJTYsWV7RThdo4K62G8hC=Anpkbr54QWbOvyVvw5uvx4+-x_DQ@mail.gmail.com
[2] https://postgr.es/m/CAPHduZC9pWm_vjznmhZNFsDZKLimqc6dKXOozLUKZVPs19zbZg@mail.gmail.com
[3] https://postgr.es/m/CA+Tgmoad7igbt46K+JHG6UEZ56Y5SVBYq5e7OjcKkgD3SStNmg@mail.gmail.com

Regards,
Manu