On Mon, Apr 14, 2025 at 04:05:40AM -0400, Andres Freund wrote:
> On 2025-04-14 16:46:22 +0900, Michael Paquier wrote:
>> We are still in early April, and I'd like to propose a cleanup of the
>> AIO code on HEAD, even if we are post-feature freeze, to not release
>> this new code in this state, implying an open item. Please note that
>> I'm OK to take responsibility for this patch set at the end, reviews
>> are welcome.
>
> I'm pretty agnostic about this happening for 18 or not. If we can do it,
> good, but if not, the impact of needing to use static variable supporting
> injection points is really rather small.
One thing that I'm afraid of is seeing this pattern grow in the code
even for code in the works, and as injection points are for tests
purposes, I'd like to think that we can be rather flexible with them.
We're still early in the post-freeze phase, so I'd say to just do it
at this point. Of course, this won't happen without a clear consensus
and if folks are happy with what I've sent.
> I'd say that the fact that injection variables are really hard to use in
> critical sections, requiring to have attached to the injection point
> beforehand, is worse.
I've also looked at providing a new flavor of load_external_function()
that would not need to worry about the allocation, even if it means
relying on MAXPGPATH. I've never come down to actually do that as
being able to load the callback in the cache beforehand is something I
think we'll require anyway. So we don't really need this new flavor
API at this level.
>> The code is shaped so as we can rely on InjectionPointCallback to define the
>> shape of a callback.
>
> I don't know what this means though?
I mean here to have all the callbacks rely on one single typedef.
I've looked some options, like having multiple typedef where some have
zero, one or mote arguments, but found that inelegant.
One thing that Jeff Davis (added in CC) has mentioned me upthread is
that he was looking at runtime arguments for injection points for a
new project of his, where he wanted to do some stack manipulation to
make a couple of corner cases cheap to emulate. I've asked his
opinion about the interface I've proposed, as well.
--
Michael
