Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 8 Jul 2026 15:29:44 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Postgres hackers <pgsql-hackers@lists.postgresql.org>,
	Heikki Linnakangas <hlinnaka@iki.fi>
Subject: Re: injection_points: Switch wait/wakeup to use atomics rather than
 latches
Message-ID: <ak3uWDZDO4QTQCFB@paquier.xyz>
References: <46821C66-E6B2-420D-BB83-E20EF36665B8@yandex-team.ru>
 <ah5Y-1t_Xfw-CU_T@paquier.xyz>
 <E9AD8D63-AD24-448F-BC9E-CC9D1CCC6D02@yandex-team.ru>
 <ah5pxKkhEGW3QGH5@paquier.xyz>
 <688F6266-3901-4C84-B27A-AF5904801A3A@yandex-team.ru>
 <ah9X1M0r-dLPgNa6@paquier.xyz>
 <0C7D1930-F8BD-45D3-980B-841F1DBE1204@yandex-team.ru>
 <EAEE7784-1CE6-43CD-9008-2F726F3761C0@yandex-team.ru>
 <ai9D5_4mBSdLixOP@paquier.xyz>
 <45DAF9CC-FAFB-4AC3-9E31-6EB77644E671@yandex-team.ru>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="8U0RVBhK57O0Z9bU"
Content-Disposition: inline
In-Reply-To: <45DAF9CC-FAFB-4AC3-9E31-6EB77644E671@yandex-team.ru>
Archived-At: 
 <https://www.postgresql.org/message-id/ak3uWDZDO4QTQCFB%40paquier.xyz>
Precedence: bulk


--8U0RVBhK57O0Z9bU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> Alternatively, we can use new capability for some other tests.
>=20
> 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

--8U0RVBhK57O0Z9bU
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmpN7lgACgkQnvQgOdby
QH3r6g/8DoOuRseDNY4ndeMt2uZsARhFOZN9M999UjHh/v9bBdXGFPqr/HaP4P2k
+cF89KVHa1Q1ioNpGNgaihrfvYxiMzyEzIudPRGPQS3rC8LYT9kbbg/ZHcESo5Pc
cqyCnuH/iB7eyeuvEg9Jv32AmhEtucRPp1Sch8srRA4h1nlH/2zRqGLfnoMYa0Ad
jFXGbpOvqsqeR4yY/LK35AeZ0ytbpimFn3TzEE7mCwD4k9xyVmeFC4Abjn1KcOhM
JxgKBX14U2vVcMIF3vhaD6O/Dh4dONQi5Qe8IsTHuSNyTefoRAQ5IkrC7LxArZt5
mGJ1+3qxiGz4W5tDN8Cw/ZE0XvQw+LJYkd0rC4qgA+XljW+lGnLx2ebTX9450ELk
bI4dtQh3N/Qg2gL+3AgVl9rt3WQkeJoBymwhQHojSaFLCW4LRMnoUTUFjK7Asn/b
pU2aZTlIztM5+avXzHBzOItDYtTiB4IqAcQexSrtN9DqZ47hqejVrnT3rnlb8UDf
mfyv1YEBKXzovItWE5Cx5zUPSgIoz8ixPx26ep4kNW7LxRC64EMOGXBbizZiodE7
a8CCXRCrxh5MjdECoddNatZiOL4p6fGKi06SrfsigTdHkbu8j4FrqqyoQiKGJcaK
4B/TNG5puGawrjhvpoAPlTYZw9ekVUnj9SeuWaKE4urJpZFOte8=
=DS7N
-----END PGP SIGNATURE-----

--8U0RVBhK57O0Z9bU--