Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 26 Feb 2026 12:33:22 +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: <aZ-_AkG3cmeTbdFn@paquier.xyz>
References: <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>
 <aZznT84Ssh8PywcH@paquier.xyz>
 <aZ2t5IZ2c7HBuDS3@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="Y0KBdy3708P7DK9f"
Content-Disposition: inline
In-Reply-To: <aZ2t5IZ2c7HBuDS3@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: <https://www.postgresql.org/message-id/aZ-_AkG3cmeTbdFn%40paquier.xyz>
Precedence: bulk


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

On Tue, Feb 24, 2026 at 01:55:48PM +0000, Bertrand Drouvot wrote:
> On Tue, Feb 24, 2026 at 08:48:31AM +0900, Michael Paquier wrote:
>> 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,
>=20
> Right but they all already call pqsignal(SIGALRM, SIG_IGN), so I'm not su=
re
> to get the point.

This design requires enabling a new signal with a signal handler in a
lot of processes that did not do that.  Enabling timeouts in a bunch
of new processes, while claiming it is fine to do, sounds like
something we should rather be careful about.  Are you sure for example
that some of the checkpointer code would not buzz on that, for
example?

At the end, this approach seems too heavy-handed to me.  I am also not
entirely convinced that enforcing that unconditionally is the right
thing to do in some cases, either.  For the bgwriter, as one example,
we have a WAL report call happening in its main loop, which is quite
good in terms of information frequency obtained.

Wouldn't some case-by-case strategic "anytime" API flush calls make
more sense for some subsystems, rather than relying on a timeout?  It
seems rather easy to misuse this design in some bgworker contexts, and
SIGALRM could also be used for a different purpose but we would block
that entirely moving on with future versions?
--
Michael

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

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmmfvwIACgkQnvQgOdby
QH2aqg//Se9YhSvHqGUXKeOB0DcnpPy0ujvtLoiRCvSYtzX3b1BBc6+hbqgs3ykE
mWakM1/uJ2XUu+O79XEejMaYEIGgzsNeUyJC6GLXeyqgCbIw/mQ2kdyszczupkw8
XunUtjHUiyou22AHVmp7pkU5ReoUxoW6afKLFwgDiJc7HTvhNAc5N1tL/pxZnY+k
T4XDCk/x3Ib5l286To4+0rSAajHvkjulDUQdNd2WNF8LEdrB1kJU3Q8zdhRfma86
PpbvM1GiwsssEIAZWaqZuENc84SiHrA55LTYw01bqHkEQvh/LtKxJ62SGjIOvkJn
SsU2qRksMdJu79vw1Gps6uqvIcR1Gsa75laAIT9caVMjwgQ26akipqMiqtn5U967
pnlrFMsGAQC3GUizHWpQ+j/fsy+N600uTjhSyRDN505HBjbbQghl4A93HhwaNjDk
gMj211/YHFPU9atptNlKGJUudNiiexY9cBVdr97OjGqh4CbxAzq196ZBliH5Y64M
dctLgeuH5YnHEpy/yS7BfcCMSLqOSJGHv2ruGMmm/tDDtlvc2K0wEtZOq5um4jkw
cEtZGeyK1eNOGRrWE1y2BwlieZpED84wavb3NseSSSHFXIvBnsLoNgJjCVaNXMQX
+9/GZ4BO4F/PTuxULVfagJyXPohlisyu7i+BQuy+k/eOH2TVMWQ=
=aA4g
-----END PGP SIGNATURE-----

--Y0KBdy3708P7DK9f--