Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 16 Mar 2026 19:22: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: <abfZ55jwCGGci6aK@paquier.xyz>
References: <aZaKVOrRO_bHsevn@paquier.xyz>
 <aZbDYMrOkeCyIubO@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0u2Vi4-PvHsFBS6aHpoi-uNQjDaLxnAwXxRuUf6ZDMs3Q@mail.gmail.com>
 <aZiD74ZVehxfgqxM@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0t1DsB5x_reGAv0AcKdKuF5FTowUx54SLnWkD3w5vH4Lg@mail.gmail.com>
 <aZwMdVBYobV41duU@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0vaB+fXHt76bi_Koj33JoerdgfMYFxHn-D1N+SPSGwL2w@mail.gmail.com>
 <aZ2TGo5bkDvYOfIw@ip-10-97-1-34.eu-west-3.compute.internal>
 <abeimWKYq-n34FrH@paquier.xyz>
 <abfLaVT5qIbPtzsQ@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="rWsrufS7v1CQKxQq"
Content-Disposition: inline
In-Reply-To: <abfLaVT5qIbPtzsQ@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: 
 <https://www.postgresql.org/message-id/abfZ55jwCGGci6aK%40paquier.xyz>
Precedence: bulk


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

On Mon, Mar 16, 2026 at 09:20:41AM +0000, Bertrand Drouvot wrote:
> I did not look closely at the code but did some testing too. I confirm th=
at
> pg_stat_io and pg_stat_wal are updated when pg_stat_report(<backend_pid>)=
 is
> triggered. But the stats update is not visible if requested through
> pg_stat_get_backend_io(<same_backend_pid>) or pg_stat_get_backend_wal(<sa=
me_backend_pid>)).
> I guess that PGSTAT_KIND_BACKEND should also get the PGSTAT_REPORT_TRANSA=
CTION
> report_context?

Yes, I guess that the transaction-level flag should be set as well for
the backend stats, due to the fact that WAL and IO stats have it set.

>> Note that this is a WIP, which is check-world stable.  One thing that
>> sticks a bit in mind now is that perhaps we should not allow the
>> function for auxiliary processes at all.
>=20
> Why?

I was feeling that there would be an issue with that, and I did not
test it in details yet.  For the checkpointer with a busy activity,
the IO stats could be interesting to see in live.

>> Perhaps we should just have pgstat_flush_pending_entries() provide a
>> correct status in line with the property set in a stats kind when we
>> try a flush while in a transaction.
>=20
> The idea would be to avoid trying to flush stats that don't have pending
> entries?

I had to work around the assert at the end of pgstat_report_stat(), to
tell that under an xact the partial flushes were OK.  I was wondering
about keeping the end assertion based on solely "force" intact, making
the flush routines return a status based on if we are in an xact.

> That looks "simpler" that the previous proposal but who would be responsi=
ble to
> call pg_stat_report()? If that's the client responsabilty that kind of lo=
ok weird
> to me. If that's the core, how would that be scheduled? I think that the
> end solution should prevent to find similar issues as 039549d70f6 fixed, =
without
> delegating to the client.

TBH, I don't like the requirement of setting SIGALRM in all the places
where we'd require it for the sake of this proposal, where
historically we have never done that, copying a mechanism that already
exists in the tree for procsigs, as the previous patch I posted proves
we could reuse.  It's also not clear to me what a correct frequency of
the stat updates should be, and why it would make sense to force that
in a GUC; we want to have some information from long-running
transactions, where I fear that we will want modularity.  A
user-settable GUC would fit with this picture, but the requirement of
planting the timeouts don't stick for me..

On top of that, I am not really convinced that there is a good reason
to remove the existing stat report calls we have already planted in
the tree for auxiliary processes, diverging from the stable branches
where these exist.  With more than one release already out with them,
there is more benefit with potentially planting more strategic report
calls where they could matter (as added in v18 for WAL senders as one
example), when we find a requirement for them.
--
Michael

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

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmm32ecACgkQnvQgOdby
QH3zXRAAjeiP6aTp3OqqBAjALN3B5JciP5S7mz7XWtvmw8JJMb8FxcHx1v383ZyY
RQStlRW55oD+3e8IPTDTJwowB74LNC1addocHfIGaYcI4DfhhQq3TL6V0VJq46Se
cM+zaDzVBfn9fv+W9Hakw9mCLYpbK1ISUW09WnBgtVAmyMO3am093SpLwW2AGxtB
CQAhJ6A1RjJYVukbeHSOkvg/m0XTv9IZx0hLX1O5bKqjvRn24D7zIJzL3vR+jqUC
W8JGhQIkzhqBTfaQMmdWQ3B5wjBtZslAW5OOCqixmLBrzwM8IZgRM06ZLH6ighbU
d/CPb070wgPUCUgdIqO8ICKnLdQABdZk7PhJJDomq2herIA9S2vOp2Q+Im0sKLeZ
rIw5FUzIxXD1sUR2dQQ69ibzU85bDEQer8nQflmc4RfNnTyoSjcb0vDOtGi3vJtd
fLWZtT1IWSymR+LpYwSGTQjQUKKkKFx+UeeNrHIhzQjjmPJE3oaUaMCo52FOCA0Q
VgYWoTXt9WdJV7oqLGyGI2tuKnaprqOzquOhrrmlkQPfEbbVrTGwiZArTCOGgfpk
+OEPF8m67gR3putcXRcowlB4aj9Bi9lFrcId0FDRG2f/EBL31rLT7r9eXyLAQBBF
lZHop1FotVExFprDV6RASQUatueYWoUjGTRygoYhxWmzhWRIkho=
=+JLn
-----END PGP SIGNATURE-----

--rWsrufS7v1CQKxQq--