Re: walsummarizer can get stuck when switching timelines

On Tue, Jul 14, 2026 at 6:35 PM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> > On 14 Jul 2026, at 17:49, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > I tried the patch on Windows and got following failure:
>
> Hi Amit,
>
> Thanks for testing! That output is exactly what an unpatched summarizer produces
> on my machine. I suspect the fix didn't make it into your build.
> Also the test passes for me on Windows CI with the patch applied [0].
>
> Could you double-check that you observe the failure?
>

Yes. This time I tried adding some basic log in walsummarizer.c to
ensure that the test picks up new code. See
extra_debuglog_walsummary_1.txt patch atop the main patch. You can see
the node-3 LOG file (003_tli_switch_node3) attached which has this
following new LOG:
2026-07-15 10:46:56.439 IST walsummarizer[14680] DEBUG: modified WAL
summarizer started
2026-07-15 10:46:56.440 IST walsummarizer[14680] LOG: inside
summarizer_wal_segment_open

Is this a sufficient proof or do you think there could be something
else I am missing or messing up?

It passed on my mac but the test took a bit longer than other tests
and the additional observation that the Windows CI passed raises a
question whether this could be some sort of timing issue in the test.
Test timing on mac:
t/001_basic.pl ....... ok 349 ms ( 0.00 usr 0.00 sys + 0.04
cusr 0.03 csys = 0.07 CPU)
t/002_blocks.pl ...... ok 1464 ms ( 0.00 usr 0.00 sys + 0.09
cusr 0.31 csys = 0.40 CPU)
t/003_tli_switch.pl .. ok 13117 ms ( 0.00 usr 0.00 sys + 0.64
cusr 1.85 csys = 2.49 CPU)

Can we first rule out that this can't be a timing issue in the test case itself?

--
With Regards,
Amit Kapila.