| 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 |
| 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) |