Re: walsummarizer can get stuck when switching timelines

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: walsummarizer can get stuck when switching timelines
Date: 2026-07-18 18:29:42
Message-ID: A44B14F1-DE37-4E45-BEB4-FAC362A1E2EC@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 16 Jul 2026, at 17:19, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> In the scenario tested by this test case, recovery works fine. Without
> the patch, node3 follows the timeline switch from TLI 1 to TLI 2 and
> continues recovery thereafter without a problem. Only WAL
> summarization gets stuck. Maybe I need to go read your thread to
> figure out why you think these are the same problem, but based on what
> the test case does, I feel like they are different problems.

I toyed a bit with your test and it is safe as long as node1 has is own
archive. So yes, technically there's no problem.

When node3 and node1 has shared archive some write activity triggers
problematic behavior.

PFA demo test to illustrate this. First step is your v1 patch intact.
Step 2 is test change to trigger the problem.

Anyway, this happens only when nodes have common archive.

Best regards, Andrey Borodin.

Attachment Content-Type Size
vAB1-0001-Prevent-walsummarizer-from-getting-stuck-at-a-t.patch application/octet-stream 16.5 KB
vAB1-0002-DEMO-recovery-follows-the-wrong-timeline-at-a-s.patch application/octet-stream 2.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-07-18 18:47:43 Re: CI slowdown due to PG_TEST_INITDB_EXTRA_OPTS
Previous Message Sami Imseih 2026-07-18 17:31:30 Re: Raise default track_activity_query_size to 16kB (from 1kB, unchanged since 8.x)