| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Maxim Orlov <orlovmg(at)gmail(dot)com> |
| Subject: | Re: Multixid SLRU truncation bugs at wraparound |
| Date: | 2026-01-09 17:58:21 |
| Message-ID: | 577C956F-3C4D-4BEF-8FEE-3B4873FB89FA@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 6 Jan 2026, at 16:53, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
> For all branches, I propose v1-0002-Add-check-for-invalid-offset-at-multixid-truncati.patch to add a check for oldestOffset == 0. That fixes the potential for catastrophic truncation with invalid offset 0.
Multixid that is used in heap is WAL-logged. WAL-logged multixact has non-zero offset.
So in non-corrupted database such as condition is impossible.
However, I observed several incidents when AI recommended pg_resetwal to users.
Proposed safeguard might be useful to prevent sprawling corruption in database.
> On 6 Jan 2026, at 16:53, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
> But for 'master', I propose the attached v1-0001-Remove-some-unnecessary-code-from-multixact-trunc.patch.
The patch simplifies the code while maintaining correctness.
The only issue I can think of is that clog, commit_ts and async are still using approach based on SlruScanDirectory().
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2026-01-09 18:03:43 | Re: pg_upgrade: optimize replication slot caught-up check |
| Previous Message | Anthonin Bonnefoy | 2026-01-09 17:21:40 | Re: LLVM JITLink attempt II (WIP) |