| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Backpatching injection point core facilities to REL_17_STABLE |
| Date: | 2025-08-07 23:46:39 |
| Message-ID: | aJU63-Ze1u_BFKs3@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Aug 07, 2025 at 12:53:12PM +0300, Andrey Borodin wrote:
> FWIW both multixact problem [0] and my recent corruption finding [1]
> would benefit a lot from having ability to do injection points down
> to PG 12.
> And while [0] is a bug that is detectable with several pgbenches, I
> have a good sounding proof that [1] can't happen at all and no way
> to detect it without waiting injection point (or similar hand-hacked
> functionality).
Thanks for the input.
It is v18 and HEAD are on par in terms of features, with only
4eca711bc991 and 7b2eb72b1b8c requiring a cherry-pick, so perhaps we
should begin with that, before moving with more cherry-picks down to
v17 as the second step?
Any thoughts from others? Would it be useful to get that down to the
back-branches?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-08-08 00:09:14 | Re: BF mamba failure |
| Previous Message | Masahiko Sawada | 2025-08-07 23:38:03 | Re: POC: Parallel processing of indexes in autovacuum |