Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 29 May 2026 08:19:42 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>,
	Andrey Borodin <x4mmm@yandex-team.ru>
Subject: Re: injection_points: Switch wait/wakeup to use atomics rather than
 latches
Message-ID: <ahjNjsg_Ls7LwASJ@paquier.xyz>
References: <aher0VsjJ8xeNgLq@paquier.xyz>
 <CA+TgmoamSXmT7uMXBw6c3YJgSSz6dYdpMsJf47jwaPH9kVbmyA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="JQY+Zz8OzOiLi+Sk"
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmoamSXmT7uMXBw6c3YJgSSz6dYdpMsJf47jwaPH9kVbmyA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ahjNjsg_Ls7LwASJ%40paquier.xyz>
Precedence: bulk


--JQY+Zz8OzOiLi+Sk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, May 28, 2026 at 08:40:39AM -0400, Robert Haas wrote:
> After reading this email, the linked-to email, and the commit message
> for the patch, I still don't have a clear understanding of what this
> is intended to fix. It seems like it's going to make the
> responsiveness worse. In general, we want to replace escalating wait
> loops with things that wake up instantly at the right time, and this
> is going in the opposite direction.

This is an exchange between responsiveness of the system and
flexibility.  I have had two complaints in the past about the fact
that the waits and wakeups were not doable due to the fact that we
rely on condition variables and latches:
- Postmaster context (lack of dsm access as one).  Heikki has
mentioned that to me once as annoying when hacking on tests there at
protocol level, at least.
- Second case as shown on the previous thread, which was a tricky
scenario involving the termination of backends.

One limitation is also related to wait event visibility, which may not
be visible in pg_stat_activity.  We could simply add a LOG entry in
injection_wait() once the old count is read, and rely on a server log
lookup in the TAP tests where we cannot use pg_stat_activity.

Compared to redesigning all the facilities that injection_points
relies on, this patch was striking me as having a good balance in
terms of responsiveness (min 10us, max 100ms) vs portability.  The
minimum threshold does not really matter much in terms of runtime on
fast machines.

Does this explanation make sense?
--
Michael

--JQY+Zz8OzOiLi+Sk
Content-Type: application/pgp-signature; name=signature.asc

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmoYzY4ACgkQnvQgOdby
QH2wFg/+ODdm/q/KjGXcCJn84FKx/IhSEF7Q1TE2HgUZQG2di+uATOTH0d/kyW+R
9TndDiMYKTGurLPiyWOgaGQRCTNOcWrgd4gU/rIpkD1A9gSbDsa0KEIfCRekZLEo
OvMLKghIew6GnSmxu6sg1T6+QKFMUBCNMvcbsKvdK3NaVDy+SHx4jWaInurhpkLE
ohOYM4gQG+fljsCVU1srna7gvJR6IlO5QVldhJ8f8A5hLlzUyKN4CbEk9ZDdf93H
ZlX3ZfE7J3BPJJHbqtUJaxYLlpAS4kfzUEODltj5O9rH1iEefD+XTuQ5Xba2seit
POnHhUaFzzLQzX3wIhR5UPniytFGHbIAYeUhBOMpagF9EXEstiAvIXo+X/RHGd2a
v+SmgjlkqIE5nHFPKhu3JR8wJgDESc9fkQMOp23U2SxONuO3AL1KxFRGcprzj5Bi
TJuUgaHHa7L35X4I1UO8QKgPdbYIKaWngGiOz9tgRWB9Z/WJDN6F8crSS/gqBlsG
5uabwq6BqHIDBHtjCwzUPVgmBG3geAVoTXTOTGsniUdrAb6EFdOd99LLK4EGtOko
SgPzc3gwYL7jRsES/dNcA6jaKt46+LoVEE65EtSAyluqEAekS/G1mPmkrTUdw11D
Q6J/7H9Tamld7wJAJt5qsdf/NmCxRt2O3CxXBkY1lUlOCE0LYCs=
=/cSQ
-----END PGP SIGNATURE-----

--JQY+Zz8OzOiLi+Sk--