On 08/07/2026 09:29, Michael Paquier wrote:
> 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.
I've got nothing in mind right now, but I remember when we started to
talk about this, I was working on something where I wanted to inject
waits before authentication. I think it was related to dead-end
backends, max_connections, reserved_connections and all that.
- Heikki
