Re: Backpatching injection point core facilities to REL_17_STABLE - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Backpatching injection point core facilities to REL_17_STABLE
Date
Msg-id DD5D9251-E824-4CA9-8B82-2B033123CCC7@yandex-team.ru
Whole thread Raw
In response to Re: Backpatching injection point core facilities to REL_17_STABLE  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Backpatching injection point core facilities to REL_17_STABLE
List pgsql-hackers

> On 28 Jun 2025, at 05:38, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Jun 27, 2025 at 02:45:58PM +0500, Andrey Borodin wrote:
>> I'm +1 on having full-fledged injection points in back branches
>> where possible. Right now I'm debugging a PG-17(probably) problem
>> where injection preloading would be handy (though functionality is
>> available via hacks, just a little more work).
>>
>> But are you going to backpatch all new features of injection points
>> in future? It's potentially x6 more work.
>
> That may be nice, but I'd be interested in seeing how things evolve
> across v17 first before taking a decision for older branches.

FWIW both multixact problem [0] and my recent corruption finding [1] would benefit a lot from having ability to do
injectionpoints 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
alland no way to detect it without waiting injection point (or similar hand-hacked functionality). 


Best regards, Andrey Borodin.

[0] https://www.postgresql.org/message-id/172e5723-d65f-4eec-b512-14beacb326ce@yandex.ru
[1] https://www.postgresql.org/message-id/B3C69B86-7F82-4111-B97F-0005497BB745%40yandex-team.ru




pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication
Next
From: John Naylor
Date:
Subject: Re: cpluspluscheck vs ICU again