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
signature.asc
Description: PGP signature
