| From: | Manu <manuelreyesbravo(at)gmail(dot)com> |
|---|---|
| To: | Daria Lepikhova <daria(dot)n(dot)lepikhova(at)gmail(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Assertion failure in WAL summarizer |
| Date: | 2026-10-22 15:38:52 |
| Message-ID: | 179268353202.893194.12175308247977690674@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Daria,
Thanks for confirming the analysis independently, and for the review
and testing.
On Thu, Oct 22, 2026 at 10:30 AM Daria Lepikhova
<daria(dot)n(dot)lepikhova(at)gmail(dot)com> wrote:
> 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.
Done in the attached v2. The comment now ends with "If the switch
point precedes the start of the current summary, SummarizeWAL() then
reports no progress." The comment on the clamp in SummarizeWAL()
already points back to summarizer_read_local_xlog_page().
> 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.
Agreed. v2 keeps only the log check, since log_contains() doesn't need
a running server.
TAP nodes run with restart_after_crash = off, so the crash shuts the
standby down instead of reinitializing it, 73-105 ms after it reaches
production in my runs. pg_ctl promote polls every 100 ms, so whether
it sees the promotion first is a race. Here promote won in 13 of 13
runs without the fix, and the v1 test then failed "not ok 1" and died
on the PID query against the stopped server. With v2 and the fix
reverted, it now ends with "failed 2 tests of 2" instead (4 of 4).
When promote loses the race, as in your run, the test still bails out
at promote. I left that as it is.
v2 applies to master, 19, 18 and 17 like v1, and passes there.
> Separately, while looking at this I found a related but different
> problem: if the switch point falls exactly on a page or segment
> boundary, [...]
Looking forward to that thread. I'm happy to run your reproducer
against v2 once you post it.
Regards,
Manu
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Fix-assertion-failure-in-WAL-summarizer-after-pro.patch | text/x-patch | 7.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-10-22 15:47:47 | Re: [PG19] A canceled notify read leaves the NOTIFY queue stuck |
| Previous Message | Manu | 2026-10-22 15:13:58 | Re: [PG19] Promotion hangs behind a backend blocked on a stuck client |