Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 19 Feb 2026 12:58:12 +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: <aZaKVOrRO_bHsevn@paquier.xyz>
References: <aYDb7g5hXnaP+5BU@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0tgr5iFuBDofX9n4SNbo-SFjzNFqTGHt7yQFAmfWBf-Rw@mail.gmail.com>
 <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="dz6PXkybTFxm8NHl"
Content-Disposition: inline
In-Reply-To: <aZVQ3nT9B6ti8whJ@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: <https://www.postgresql.org/message-id/aZaKVOrRO_bHsevn%40paquier.xyz>
Precedence: bulk


--dz6PXkybTFxm8NHl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Feb 18, 2026 at 05:40:46AM +0000, Bertrand Drouvot wrote:
> PFA a mandatory rebase (nothing that needs review) due to a92b809f9da1.

I don't find the design of this patch appealing, and my mind points
towards two pieces of it:
1) The new requirement related to pgstat_schedule_anytime_update()
that a stats kind needs to call to enable a timeout.  This partially
doubles with pgstat_report_fixed.  And I suspect that this extra set
of requirements, introducing a new level of complexity for in-core
stats kinds as well as extension developers, would be the source of
more bugs.
2) The timeout requirement itself, relying on a timeout threshold
controlled by a backend-side configuration.

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?  One such example is
LOG_MEMORY_CONTEXT, where we have a SQL function that is able to tell
to a backend that it needs to do something.  I could see various
benefits to this approach, because it gives more flexibility with the
timing of the stats flushes, which may not be a backend-side only
policy:
- Use a cron bgworker in the backend, that scans pg_stat_activity, for
example for long-running transactions based on a threshold.
- Do the same periodic scan of pg_stat_activity, but from a client
application.

The PROCSIG would need to set a flag in a new SIGUSR1 handler that
would trigger the flush for the stats kinds that have the
out-of-transaction property set once we go through in
ProcessInterrupts().  We already have a pgstats report call there,
hence it is a matter of removing the timeout requirements as presented
in the patch, and let client applications when this should happen.
The property of tracking which stats kind is surely important, Sami
has reminded that a couple of hours ago that there are some stats that
we should not flush even if we get an async request.  Another thing
that I am doubting about is if using the same async flush threshold
makes sense for everything.  Long-running transactions, for example,
mostly would not care much even if we use an interval less aggressive
than what a WAL sender sees.

Not a fan of the hardcoded sleeps in the tests, either.  On fast
machines, these tend to waste in runtime because a process stands idle
doing nothing.  On slow machines, tests could be unstable if a sleep
takes longer than it takes for the environment to react to a condition
of the test.
--
Michael

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

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmmWilQACgkQnvQgOdby
QH2geQ//fwHjFDFspB+UOUaPdy/jnE2e7y/dcQUnX9xJt71n6S3nKQ213ozLM7W/
s6VwD0VymWxEqaWDHLcUYj4og40vb8S0/LbuVyXYkb+DahxXWupUQg0hFhx7UOzd
f1dSSAy1Pih752b0zrxyW/pnSFS4ecWDKXC/xDkrEd1D/I/5MZ97siHO09KggOtc
2O2XmQpjwEXP5b2oqIvKMGIWkwLLylv8Iancskxy3hTzl+4bIKYsYts0klMGtESC
oCF0PQ2EAmG6nJdG2Gu1YzI03LF2ICQK1X2X4GYitRveR1bPDUczncu6psA+HaNM
qQzn+fCdKpuq8XIpBNwY4p6KkOKvFGqb4Y8cwu8P0rmnWbZ9V2ZK1jk3+by/X+Cl
Qk13Du8H3ZymEeSk52f+LaJP634uhw6qeM4VcXDFApY32HlRsk35V+LMjja43TAY
OuCIagj95/m6DLpNczGyXUw56gJTSzYaKR7opCChC4j1i2bfWOGxWXs058KhxHWm
uZE7aV0o3TEXD0RrkBMbmYc/anaqEfBriC2kCl+gEqLcUVN5ce9Go0iK7skXbojl
1gBPntvf3Z9ObXxFyY+wTQRPMh9Sujvrc03ulW7C3d0QeWWEO10bMBTdaUDogs3Q
oz+bng+Q4oHeEWZr1tAHiHC1GLbNM3oFP18xSRm47sPkZWlb30s=
=uUg+
-----END PGP SIGNATURE-----

--dz6PXkybTFxm8NHl--