Re: WAL-logging facility for pgstats kinds

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Cédric Villemain <Cedric.Villemain@data-bene.io>
Cc: Andres Freund <andres@anarazel.de>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-02-16T23:27:46Z
Lists: pgsql-hackers
On Sat, Feb 15, 2025 at 10:31:33AM +0100, Cédric Villemain wrote:
> Additionally, there is significant potential for external applications to
> leverage the PostgreSQL stats system to collect metrics instead of relying
> on relational tables, promising a highly efficient solution. In such cases,
> providing a mechanism to replicate this information could be very beneficial
> for end-users.

Hmm.  You mean with the extra addition of a hook around
pgstat[_shmem].c so as it would be possible to take some custom action
when pushing the stats to the pgstats dshash or for the fixed-numbered
stats?

> Though I also support Andres' position to avoid abusing WAL in this context,
> I am slightly more flexible: this exception would apply only if there is a
> clear separation between stats essential for PostgreSQL (or its extensions)
> to function correctly during or after a switchover, and those (stats or)
> metrics that are irrelevant to PostgreSQL itself.

All these parts are doable even today outside of core with a custom
RMGR, so it's not like there are no solutions in place.  The
introduction of a pgstats callback that can attached to a stats kind
is able to enforce a stricter rule in the backend, at least, without
the need to consume a bunch of RMGR IDs for that.  (It is possible to
have one RMGR used across many extensions, clumsy but doable.)
--
Michael

Commits

  1. Move information about pgstats kinds into its own header pgstat_kind.h