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
-
Move information about pgstats kinds into its own header pgstat_kind.h
- d35ea27e51c0 18.0 landed