Re: injection_points: Switch wait/wakeup to use atomics rather than latches

On Tue, Jul 07, 2026 at 02:51:04PM +0500, Andrey Borodin wrote:
> So the question is whether to rewrite that reproducer on top of these
> two patches. This design goes far beyond the minimal
> plan you sketched (latch-free wait, attach() with an optional PID, then
> the test), and that you were not sure the ProcKill case alone justifies
> the churn. Before writing it I would confirm it really needs the
> filesystem parts and is not better served by something simpler.
>
> Alternatively, we can use new capability for some other tests.
>
> WDYT?

The hard part is that the implementation choices are driven by the
needs, where we may want to be able to do the following things without
having to touch SQL:
- Register a wait() at very early stages.
- Know from a client perspective that a PID is waiting, as we may not
have access to pg_stat_activity.
- Trigger a wakeup.
Your patch is able to achieve all of that, but it may be better to
know better about more use cases folks have seen before taking any
hard decision.

Here, one good case that I could see in the tree is 007_pre_auth.pl,
that uses currently as a workaround a background connection to create
a wait point. We could switch that to register a wait early, but the
impact is limited.

@Heikki, what kind of ideas did you have for some of your toy tests
recently, particularly with the protocol area? The protocol tests now
in the tree use errors (backend-initialize, GSSAPI and SSL startup
points), not waits and/or wakeups.

Applied the patch that removes the condition variable dependency, btw.
that's one thing less to worry about.
--
Michael