On Tue, Feb 20, 2024 at 05:32:38PM +0300, Andrey M. Borodin wrote: > I will try to simplify test to 2-step, but it would be much easier > to implement if injection points could be awaken independently.
I don't mind implementing something that wakes only a given point name, that's just more state data to track in shmem for the module. > No, "prepared injection point" is not about wait\wake logic. It's > about having injection point in critical section. > Normal injection point will pstrdup(name) and fail. In [0] I need a > test that waits after multixact generation before WAL-logging > it. It's only possible in a critical section. It took me some time to understand what you mean here. You are referring to the allocations done in load_external_function() -> expand_dynamic_library_name() -> substitute_libpath_macro(), which is something that has to happen the first time a callback is loaded into the local cache of a process. So what you want to achieve is to preload the callback in its cache in a first step without running it, then be able to run it, so your Prepare[d] layer is just a way to split InjectionPointRun() into two. Fancy use case. You could disable the critical section around the INJECTION_POINT() as one solution, though having something to pre-warm the local cache for a point name and avoid the allocations done in the external load would be a second way to achieve that. "Prepare" is not the best term I would have used, perhaps just have one INJECTION_POINT_PRELOAD() macro to warm up the cache outside the critical section with a wrapper routine? You could then leave InjectionPointRun() as it is now. Having a check on CritSectionCount in the injection point internals to disable temporarily a critical section would not feel right as this is used as a safety check anywhere else. -- Michael
signature.asc
Description: PGP signature
