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
signature.asc
Description: PGP signature
