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

Hi Michael,

You suggested driving the module's wait points through the filesystem
instead of mapping shared memory out of process. Here is that, rebased
on your atomics commit. It is a test-module-only change; the core
injection point registry is untouched. This message and the patch is
AI-editorialized for readability.

Design
------

Control dirs and files live under pg_injection_points/ in the data
directory:

pg_injection_points/<point>/ attaches <point> as a wait point
pg_injection_points/<point>/<pid> that backend is waiting at <point>

The module scans this directory once at postmaster startup and attaches
a wait point for each subdirectory, so a test can arm a point before the
server is up (shared_preload_libraries is required for that). When a
process reaches the point it creates its <pid> file and waits, polling
with stat() until the file is removed, in addition to the existing
wakeup counter. So an out-of-process test can:

- arm a point with mkdir, before SQL is available;
- see which backends are blocked by listing the directory;
- wake one specific backend by unlinking its <pid> file.

No SQL connection, no platform-specific code, and no out-of-process
access to shared memory.

The scan is deliberately one-shot at startup. If a consumer ever needs
to (re)load points from the filesystem at runtime, that can be added
later as a dedicated injection point action (say a "reload" type); I
think we grow the facility only as the tests actually require.

The test question
-----------------

But in this project we grow the facility only when a test actually needs
it, so the real question is which test justifies this one.

The first case that seems to call for it is the ProcKill lock-group /
procLatch recycle race [0]. On that thread you concluded that
a wait point inside ProcKill() cannot use the latch-based wait, because
the fix (84b9d6bceab6) now disowns the latch earlier, and that the test
had to lean on statement_timeout to keep the leader parked long enough
- which is an anti-pattern. You (IDK, maybe someone else) suggested
switching the wait to a latch-free shmem flag on HEAD; that is your atomics
commit, and this patch builds on it.

What the filesystem adds on top is the observability that was still
awkward there. Instead of statement_timeout and an unreliable
pg_stat_activity (or query_until banners a la 011_lock_stats.pl), the
controller just waits for pg_injection_points/<point>/<pid> to appear
and then wakes that exact PID. It also sidesteps the
before_shmem_exit(injection_points_cleanup) hook that detaches a
self-attached point before ProcKill runs, since the point is armed by
the startup scan rather than by the victim.

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?

Thank you!

Best regards, Andrey Borodin.

[0] https://www.postgresql.org/message-id/d2983796-2603-41b7-a66e-fc8489ddb954@gmail.com