Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 5 Mar 2025 08:23:32 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Tomas Vondra <tomas@vondra.me>,
	Thomas Munro <thomas.munro@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Refactoring postmaster's code to cleanup after child exit
Message-ID: <Z8eLdLVWweWVLsin@paquier.xyz>
References: <a102f15f-eac4-4ff2-af02-f9ff209ec66f@iki.fi>
 <poxjp7ireyrvk37o4rq3vm2b3otzhmg3ui4ptnfilyiemns4jt@pbqmi2u5y5rb>
 <8e710eaa-fcfe-4a0b-ae90-87743083e777@iki.fi>
 <af1f0c44-c23c-42f0-98fb-e715ef780f76@iki.fi>
 <82eb454e-f9e0-433c-89f5-69f03b09ca32@vondra.me>
 <31b798ca-c150-4fc9-befe-300dd8bbda3c@iki.fi>
 <c576eddd-13da-4bad-a760-c98dfe9a314d@vondra.me>
 <574340ca-c90e-4086-9ae2-cd2f1359e989@iki.fi>
 <4d964960-72fa-4741-8a7c-879b958eaa29@iki.fi>
 <gdojfusnbe3ae47n6qjezclpv4462xbdc2ssoadtyklgdw5dqb@b4r5yw3fcifm>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="vTU432wnFfUYy3oS"
Content-Disposition: inline
In-Reply-To: <gdojfusnbe3ae47n6qjezclpv4462xbdc2ssoadtyklgdw5dqb@b4r5yw3fcifm>
Archived-At: 
 <https://www.postgresql.org/message-id/Z8eLdLVWweWVLsin%40paquier.xyz>
Precedence: bulk


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

On Tue, Mar 04, 2025 at 05:58:42PM -0500, Andres Freund wrote:
> On 2024-12-10 12:00:12 +0200, Heikki Linnakangas wrote:
>> 2. Move the pgstat_bestart() call earlier in the startup sequence, so th=
at a
>> backend shows up in pg_stat_activity before it acquires a PGPROC entry, =
and
>> stays visible until after it has released its PGPROC entry. This would g=
ive
>> more visibility to backends that are starting up.
>=20
> We don't necessarily *have* a PGPROC entry for that backend when we run o=
ut of
> connections, no?

Exactly.  If I got this thread's argument right, you cannot have a
PGPROC entry that could be plugged into pg_stat_activity that early
during the startup process when collecting the startup packet.

> For this test, could we perhaps rely on the log messages postmaster logs =
when
> child processes exit?
>=20
> 2025-03-04 17:56:12.528 EST [3509838][not initialized][:0][[unknown]] LOG=
:  connection received: host=3D[local]
> 2025-03-04 17:56:12.528 EST [3509838][client backend][:0][[unknown]] FATA=
L:  sorry, too many clients already
> 2025-03-04 17:56:12.529 EST [3509817][postmaster][:0][] DEBUG:  releasing=
 pm child slot 2
> 2025-03-04 17:56:12.529 EST [3509817][postmaster][:0][] DEBUG:  client ba=
ckend (PID 3509838) exited with exit code 1
>=20
> I.e. the test could wait for the 'client backend exited' message using
> ->wait_for_log()?

Matching expected contents in the server logs is a practice I've found
to be rather reliable, with wait_for_log().  Why not adding an
injection point with a WARNING or a LOG generated, then check the
server logs for the code path taken based on the elog() generated with
the point name?
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmfHi3QACgkQnvQgOdby
QH0SrRAAoQw9537FTf5mQbl0fpZYs4OgmXSygmnLNk52Sjdl0UX/3xMWR1U5Kq/D
deAjYB10KjBQbdQz2LlGgwKfju5wdVnXQNy6Pi5kGrJtF6NxK2CkXHi2On06zpjB
f9NPNGjMj+qUAEvZHTF/GM8sYe1evwjBGS1p8/plDZDRpaF0zlgKQ0eElOTygB/b
gIqOsKgGj8lX1g1G1Wie0HhWEdCtGd5A1PO6hD2UQ6fraUKdUj9++eg17cAJZFHZ
YQEmIL6fVUvJ7Rq68YAjjkGOGq7QvYSDv8p01Cgu0QRqDtHmk2H9B9ToKBlnqNIA
jIkL1lMp1lZQM6QKwnKwXrh5EmWDXMV4F+E7Tgac9XeocKjXFPYcdxNmV47PgPrK
4/Y3Z7eZixvRsdxggNKMMAroAXNJFx7S9Gm8bHC/3saEFrPLbjbfSaPFqp6D8zrF
uRWhwSEQyVHMpW778ATGFQVPsV+IKTIZTwO+ARhVfatoJECaXqeldIH4Ydtf82vF
ZfDY6ZiMFL1LDTroaa0dG9SKCseLgSSGOJFL9BVjthPHWinwLWCfxqKMP+42nDII
XMJP0aO59R/RlRydYUk9jmk2YlWWB0rkyQ2EaBSIeMmAye0p4bc8AlzOL7R0p/1B
Vl+L8eCnbHJMlXM1S9EkkRMKUsmIIH/ACM8s1XJjGhr4VM4k2HA=
=4X6d
-----END PGP SIGNATURE-----

--vTU432wnFfUYy3oS--