public inbox for [email protected]  

help / color / mirror / Atom feed

From: Heikki Linnakangas <[email protected]>
To: Michael Paquier <[email protected]>
To: Andrey Borodin <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Postgres hackers <[email protected]>
Subject: Re: injection_points: Switch wait/wakeup to use atomics rather than latches
Date: Wed, 8 Jul 2026 10:17:39 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

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

view thread (21+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: injection_points: Switch wait/wakeup to use atomics rather than latches
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox