On 12/02/2025 01:50, Michael Paquier wrote:
> On Mon, Feb 10, 2025 at 11:43:30AM -0500, Andres Freund wrote:
>> Because I saw this being moved to the new CF: I continue to *strenuously*
>> object to this design. As outlined upthread, I think it's going into the
>> completely wrong direction.
>
> Right. FWIW, I'm not sure that we can absolutely just discard a
> possiblity like what this patch is doing, but I see your point that it
> may not fit into the final picture, depending on what we finish with.
> I'll go discard that for now, keeping it aside in case.
I am developing (WIP) an extension to add a facility similar to
pg_replication_slots, but for statistics or metrics. On one side, it
would allow the registration of external "stats plugins," and on the
other side, it would enable the consumption of whatever these plugins
return. I believe a similar idea may have been proposed in the
past-perhaps involving opening a dedicated port for accessing
stats/metrics-but I haven't yet searched for related public talks or
archives.
This approach makes it easy to envision a background worker on a replica
that connects to a stats slot and processes the received stats/metrics
as needed.
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.
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.
---
Cédric Villemain +33 6 20 30 22 52
https://www.Data-Bene.io
PostgreSQL Support, Expertise, Training, R&D
