Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 24 Feb 2026 08:48:31 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>, Fujii Masao <masao.fujii@gmail.com>,
	pgsql-hackers@lists.postgresql.org,
	Zsolt Parragi <zsolt.parragi@percona.com>
Subject: Re: Flush some statistics within running transactions
Message-ID: <aZznT84Ssh8PywcH@paquier.xyz>
References: <CAA5RZ0sqJzpBZnOY3rOy5x7+WL_UDnoMkn2S_ZoXPPOWZkXSbA@mail.gmail.com>
 <aYXL6XmVABORjGF5@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0tK=-Dukr4ofmKpPSK4-LwqrGXmzkqGoMuJKPXnGW3=AA@mail.gmail.com>
 <aZLVDJLTiFlxsWZi@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0tPsU_bCATn-Wtf8hMaKmrCwfxtLcY9Pp3NQPpLrH2G_Q@mail.gmail.com>
 <aZQTCJJm61J/X4nC@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0vDh+vbE5SY-+azQBxEhXrywaXGrK_Qn8DKEBwNsrDH_Q@mail.gmail.com>
 <aZVQ3nT9B6ti8whJ@ip-10-97-1-34.eu-west-3.compute.internal>
 <aZaKVOrRO_bHsevn@paquier.xyz>
 <aZbDYMrOkeCyIubO@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="Xku8+Uc6A9t7wHbs"
Content-Disposition: inline
In-Reply-To: <aZbDYMrOkeCyIubO@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: <https://www.postgresql.org/message-id/aZznT84Ssh8PywcH%40paquier.xyz>
Precedence: bulk


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

On Thu, Feb 19, 2026 at 08:01:36AM +0000, Bertrand Drouvot wrote:
> On Thu, Feb 19, 2026 at 12:58:12PM +0900, Michael Paquier wrote:
>> 2) The timeout requirement itself, relying on a timeout threshold
>> controlled by a backend-side configuration.
>=20
> What are you concerns with this?=20

I am concerned about the three additional points/requirements:
1) The need for all processes who want to flush non-transactional
stats to set up timeouts, unconditionally, which is what the patch
shows with the new InitializeTimeouts() calls added for example for
auxiliary processes.  This forces the use of SIGALRM in these
processes, with a new handler, and feels like a requirement too heavy
for the sake of some stats flushes.  This requires an extra
unconditional RegisterTimeout(), as well.
2) The need for all the stats to call pgstat_schedule_anytime_update()
in strategical places.  This is less of a burden compared to 1), but
this leads to more complications in these code paths with the coding
requirements, especially for custom stats kinds.
3) Enforcing a flush timeout unconditionally.  One thing that slightly
concerns me here is that it seems easier to misuse compared to a
client-based facility, where a too aggressive setup could stress more
the server-side pgstats.  It is true that the client-side could be
misused too.

My main worries are mainly around 1), I guess, with the new SIGALRM
handler requirements for all auxiliary processes.  Using a procsignal
path would allow us to rely on a solution that has the same
flexibility, combined with strategic additional flush calls that we
could spread depending on requirements we want to enforce in some
processes, like in the WAL sender, or perhaps the checkpointer.  That
seems more careful in the long-run, and this can rely on the interrupt
processing for the job.  The addition of the property to track if a
stats kind of OK to flush outside a transaction boundary is also
critical to have, of course.  I am sold to the point point of the
design about this new property tracked in the stats kind meta-data.

>> With that in mind, wouldn't it be simpler if we introduced an API that
>> could be used from client applications instead, in a model similar
>> what we do for procsignal.c/h?=20
>=20
> That's another angle to look at it but I think that giving this responsab=
ility to
> the clients would not solve the concerns we had in [1] (that led to 03954=
9d70f6
> and to this thread). It seems to me that a solution/design that does not =
allow
> us to "revert" 039549d70f6 does not suit our needs. Thoughts?

039549d70f6 goes in line with the "client" prospective, where I would
like to think that strategic flush calls are more flexible.

> Yeah, after our off-list discussion yesterday, I tried to implement the s=
ame
> trick that f1e251be80a has done with injection points (nice trick by the =
way!),
> but that led to:

In this case, avoiding an injpoint allocation in a critical section
would be a two-step process:
- INJECTION_POINT_LOAD(), before the critical section, to warm up the
cache and do all the allocations.
- INJECTION_POINT_CACHED() with IS_INJECTION_POINT_ATTACHED()
(optional), to run the point, in the critical section.

This tactic is already in use in the tree.  You would have to use a
more complicated scheme to make sure that the wait machinery is
initialized when using it in a critical section, but that can be
worked around as well.  See my "state-of-the-art" work of
15f68cebdcec, which, well, happens to work.  Not really the best work
ever with two points, but it works for this purpose.  :D
--
Michael

--Xku8+Uc6A9t7wHbs
Content-Type: application/pgp-signature; name=signature.asc

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmmc508ACgkQnvQgOdby
QH2HcQ/+N7gYhtqVbZ/GDAVFRjYb8syiCudeXLOc5lA0t6yWKBOdA7DKn57WBvpn
ZK65fnjRDhgYvLWtwT7dVkz0NiKtx4EjkvUiESc2Q1e8vqQ0tXJKz9eclNGheO3b
4luHyO7vpVLnyfikiJIXE59iy0rHYspmg24r1R48pIqJtqV51ZYt/uvWCthMNjjC
giKLyoA3kheVLzOl5ZbzepKdvEbbnxpQjX6Ol6DA4YWWKlUXkNW4+erQiZMTr6Zz
z3LROodOknX4DX1JC9hOss4kiMINtGzth2oLMXmbADKg2xVh5UuBPjXx8pukG5qT
vWW9REaP9OALwcZpYGmjqjAS92E8N6S5OOVwEaJlnH1htZlXsUIS7sxrVjSihF76
vhRL+uXg3mH3Fh3xY4fof8Px0Wu0O+DK9vepZfwU8dimK6NHhtvUprp4XFBZ+EB1
PNGMubfr2k1ufkRB16fOMTjS+rqMn3oW1F23R9Rs4jtzGyKYXsI0hBJtP9UcZlNk
jX40Npx8UhI+NuR7Hhl8nEAu5KqZHrTZq1nHrW2x9C/V9A7KU9ew3Fcjfx9o5Z2z
r5z+0AQTp+nFq2CXhDITlg1aEwmservcGRlVxw/hN/Exr/n9KuHkSZTAnlL/GN2F
qshByFmZTDZVGQSdjp5IT904+MOhG0DL1/igXRUNLxL5kfzssCU=
=QPb6
-----END PGP SIGNATURE-----

--Xku8+Uc6A9t7wHbs--