On Tue, Jan 21, 2025 at 07:19:55AM +0000, Bertrand Drouvot wrote: > PFA v6 that now relies on the new PendingBackendStats variable introduced in > 4feba03d8b9. > > Remark: I moved PendingBackendStats back to pgstat.h because I think that the > "simple" pending stats increment that we are adding in xlog.c are not worth > an extra function call overhead (while it made more sense for the more > complex IO > stats handling). So PendingBackendStats is now visible to the outside world > like > PendingWalStats and friends.
You are re-doing here a pattern I was trying to avoid so as we don't copy-paste more checks based on pgstat_tracks_backend_bktype more than necessary. I am wondering if we should think harder about the interface used to register WAL stats, and make it more consistent with the way pg_stat_io is handled, avoiding the hardcoded attribute numbers if we have an enum to control which field to update in some input routine. As we have only five counters in PgStat_PendingWalStats, the result you have is not that invasive, true. Are you sure that the interactions between pgWalUsage, prevWalUsage and prevBackendWalUsage are correct? As far I got it from a code read, prevWalUsage, prevBackendWalUsage and their local trackings in pgstat_backend.c and pgstat_wal.c rely on instrument.c as the primary source, as pgWalUsage can never be reset. Is that right? -- Michael
signature.asc
Description: PGP signature
