Re: Re: Assertion failure in WAL summarizer

Hi Manu,

I tried the series (v2-0001 from upthread plus your v1-0001 and v1-0002) on
current master. The code applies unchanged; only the pg_combinebackup
meson.build hunk conflicts now that 013_summary_order is in, so I added 014
and 015 to the test list by hand.

Linux aarch64, --enable-cassert --enable-debug --enable-tap-tests:

- pg_combinebackup and pg_basebackup pass.
- 014, 015 and Shihao's test (run as 016) pass 3 of 3 with the series. With
the same tree but master's walsummarizer.c and basebackup_incremental.c,
all three fail 3 of 3. On this cassert build Shihao's test fails earlier
than in his report: the summarizer hits Assert("end_of_summary_lsn >=
current_lsn") after promotion, so the backup fails before the data can be
checked.
- pg_walsummary's 004_promote_past_target times out in its setup with 0002
applied, as you said: the standby never summarizes past the target. So the
v2 test needs a different setup if 0002 goes in.

Regards,
Sai Pranav

On Mon, Oct 26, 2026 03:35 AM, Manu <manuelreyesbravo(at)gmail(dot)com> wrote:

> 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=Anpkbr54QWbOvyVvw
> 5uvx4+-x_DQ(at)mail(dot)gmail(dot)com
> [2] https://postgr.es/m/CAPHduZC9pWm_vjznmhZNFsDZKLimqc6dKXOozLU
> KZVPs19zbZg(at)mail(dot)gmail(dot)com
> [3] https://postgr.es/m/CA+Tgmoad7igbt46K+JHG6UEZ56Y5SVBYq5e7Ojc
> KkgD3SStNmg(at)mail(dot)gmail(dot)com
>
> Regards,
> Manu
>