Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 25 Nov 2024 10:06:44 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: per backend I/O statistics
Message-ID: <Z0PNpAjhcS7S-1LI@paquier.xyz>
References: <ZzWZV9LdyZ9aFSWs@paquier.xyz>
 <ZzX7Y5i56UrOtlRC@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZzvuScIJW9kwnuyE@paquier.xyz>
 <Zzy8x7fGkWEKB7SF@ip-10-97-1-34.eu-west-3.compute.internal>
 <Zz0m1k03k5LA_c8S@paquier.xyz>
 <Zz3wIuQUJysX5O3d@ip-10-97-1-34.eu-west-3.compute.internal>
 <Zz5gMM9w59guO9S_@paquier.xyz>
 <Zz9sno+JJbWqdXhQ@ip-10-97-1-34.eu-west-3.compute.internal>
 <Zz_gHQ2g8MUe8oJ1@paquier.xyz>
 <Z0A3pmORCbhRe0Ug@ip-10-97-1-34.eu-west-3.compute.internal>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="rx/1FcJvdCqVxY8N"
Content-Disposition: inline
In-Reply-To: <Z0A3pmORCbhRe0Ug@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: <https://www.postgresql.org/message-id/Z0PNpAjhcS7S-1LI%40paquier.xyz>
Precedence: bulk


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

On Fri, Nov 22, 2024 at 07:49:58AM +0000, Bertrand Drouvot wrote:
> On Fri, Nov 22, 2024 at 10:36:29AM +0900, Michael Paquier wrote:
>> Hmm.  created_entry only matters for pgstat_init_function_usage().
>> All the other callers of pgstat_prep_pending_entry() pass a NULL
>> value.=20
>=20
> I meant to say all the calls that passe "create" as true in pgstat_get_en=
try_ref().

Ah, OK, I think that I see your point here.

I am wondering how much this would matter as well for custom stats,
but we're not there yet without at least one release out and folks try
new things with these APIs and variable-numbered kinds.  Allowing
pgstat_prep_pending_entry() to return NULL even if "create" is true
may be a good thing, at the end, because that's the only way I can see
based on the current APIs where we could say "Sorry, but the stats
have not been loaded yet, so you cannot try to do anything related to
the dshash".

=46rom my view having a kind of barrier would be cleaner in the long
run, but it's true that it may not be mandatory, as well.  pg_stat_io
is currently OK to be called because the stats are loaded for
auxiliary processes because it uses fixed-numbered stats in shmem.
And it means we already have early calls that add stats getting
overwritten once the stats are loaded from the on-disk file (Am I
getting this part right?).

Anyway, do we really require that for the sake of this thread?  We
know that there's only one of each auxiliary process at a time, and
they keep a footprint in pg_stat_io already.  So we could just limit
outselves to live database backends, WAL senders and autovacuum
workers, everything that's not auxiliary and spawned on request?
--
Michael

--rx/1FcJvdCqVxY8N
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmdDzaQACgkQnvQgOdby
QH2x/g//Vd85p6IMlLAf0pgNOJXAXASa7+9m6g7ZFYB1fUIuNiw5UhwOaTGsA4bV
4NmiYI9pNycugfIp/i06ubpcrCudOuNLkeWM7fo6J20YbTTydWniibkfaGqNon0A
DhzUS51UKA8E00GjGcPk3/qQeni9s/mOzEnz5EL6Q01KkAFtyu7k6vlW6FZV3Pxv
PsxA5S9msWorf3rtjPr9gocv98JznvX1mqapMaIy9Jq4MHwGKwAG4c1mmN0OmVVz
U1yVEAKFy6E5yqTJGl7mUN/OJTIkUMiq8T56s3KFVx8Pt5MRvD/zqGa9IbypQ8z5
8Lq3PTk1tp3mMU1U0FDGDFZXTWjYoH0NKsXOG9LO81tmSERE14NKP+pua1iquTGw
blyffIJnUoEY1uqa300q/5EMRSuTl5/tg2XeWQ+6VzTf99m5+vVDzI7/BXSuycyx
0ltg0qDfWwqf7Zf7EKmUsrltLYkeBI23wgua2wdSFGZBI1GsAwm4nDlYUro+5B0F
RRaNxQlu6y5/DnFlpf59sJUwZ+kuVnXJLWi6qycsAU5+06B9pa6nxUHJ+7MdNkNT
95DW2mnmip3pGlgJtX9mJ5q0jOIdODn/PyIXUI6gHB5CyfGwt55s1aB7w3g8Uv+4
pm78m9ZdveKX0zEnOZ87yUGCyfPgYofkpiCLWeE+ygM/+119ods=
=y0c4
-----END PGP SIGNATURE-----

--rx/1FcJvdCqVxY8N--