Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 15 Jun 2026 09:14:31 +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: <ai9D5_4mBSdLixOP@paquier.xyz>
References: <b34ff5d0-eefe-4f51-91c4-59e5c2aef25e@iki.fi>
 <F6DE375E-8E88-4B70-A671-CC14432B85C0@yandex-team.ru>
 <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="aMQG3DFkC7ukMd1s"
Content-Disposition: inline
In-Reply-To: <EAEE7784-1CE6-43CD-9008-2F726F3761C0@yandex-team.ru>
Archived-At: 
 <https://www.postgresql.org/message-id/ai9D5_4mBSdLixOP%40paquier.xyz>
Precedence: bulk


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

On Sun, Jun 14, 2026 at 02:23:54PM +0500, Andrey Borodin wrote:
> The same revision also closes an unrelated init race: when two processes
> create the backing file at once, the loser could map it before the winner
> sized it (SIG-something on first touch). The attach path now waits for the
> file to reach full size before mapping.
>=20
> CI is green. Same two patches on top of your atomics commit. Let me know
> if this prototype goes radically wrong way.

You may find my reply surprising (or not), but using a client tool to
bypass the SQL protocol is super invasive in terms of the in-core
changes, and I'm -1 on that.

Test tooling should rely on simple facilities, and you are
re-implementing quite a few things here that come with a new class of
bugs and what look like design issues to me due to the invasiveness:
- Reimplementation of the registry protocol for file mapping.  That
may be useful for other things, and there may be use for a refactored
in-core API, but I don't see why we should use it here:
- Mirroring of internal structs for shmem manipulation.
- Core data updates with zero locking.

I am wondering if we are not overcomplicating things here..  How about
this idea instead of 0002 and 0003, for paths that cannot rely on some
SQL:
- Let's use a file-based markup, located in a injection_points/ in the
data folder.
- When attaching a wait point, write a marker, say wait_$POINT.
- On wakeup, write a wakeup_$POINT.=20
- The wait routine does periodic checks of the wakeup_$POINT file,
using a stat().

It depends on how much we want to achieve, but forcing a postmaster to
wait at an early startup sequence would then be something like:
- Add the a wait markup.
- At startup, shared_preload_libraries scans the pg_injection_points/
repo, fills in its shmem state by calling InjectionPointAttach().
- postmaster hits the injection point, calls injection_wait()
- Test does what it wants while the postmaster waits, manipulates
states.
- Test script drops a wakeup file.
- Postmaster sees the file, continues its startup sequence.
This means one cannot set an injection point until
shared_preload_libraries is loaded, of course.  Cleanup logic feels
kind of nice: test cleans his stuff, or just remove
pg_injection_points/ at shutdown with an exit callback.  No platform
specific logic, only FS checks.

This means a bit higher latency, but it eliminates a full class of
bugs due to the fact that it is simpler.  This would need to live
alongside patch 0001 so as a _PG_init() can be loaded when the
injection_points lib is loaded; we're still going to need it to fill
the shmem info with the wait slot being occupied.
--
Michael

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

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmovQ+cACgkQnvQgOdby
QH1XRxAAlCE7dpE2F3ppWlF7zwDWbLmjua4QxQub7Ss0PWmvrInn7BGdx/Ngy405
4KVn936ABwfYNpOn5SFfdoL+wY41noZeMZjPD0+rep/9y385lwWZqGu9NnnnyaYx
g6kkDJ8UMVxY+2aI2GWQND3qH8b+fPPbBODjelHC9LHIt4O73RUyiY8dLvWJrIxI
yxk0yx6A5V/RBpvtvmUezrX4rH2sYp0tuGBcTE3bZiLqMztAw0tk71CZrHjQmUWM
hvd4zer1V4lkydOY/ib1/8afAuPrJ2VseiV9TGR71IB9VdvpbB83d9CjxXZfm6El
7XKJEf1rYswaY/gRW7D8e80W62uSrefo91KvxuDMOlUi5NsAHC7cz+kx2OVtEqZH
RHBqxOYXUjlOeORhRkpMQsaQ8K81PDUm0W46c10iPJ/IIBUIDAAMJF1+3FheCN/k
wd3riRm0K92r0bBDca39TJfwGcEa02AHzW79OrPG39MS4F9YRQE9h9n3uqrrHnG1
zoIYL4V4IHkf8pwwWBWtSRRJp8JT9FyVbQqsc+LHAq+OAOxLFucNwIu4oEmbRdAs
5a5HEBKDxiUF399rqvS23TmMtZEPq3GTXxCL9JTXvjZ3FB80kLsZbjyeqt3kjLQ+
9NQxE1z6EoYCGJwr/dm/YpB6EpN/3Y5u0uxAqY7Ohv2t+GzU/pg=
=yGPN
-----END PGP SIGNATURE-----

--aMQG3DFkC7ukMd1s--