Re: [Proposal] Adding callback support for custom statistics kinds

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>

To: Sami Imseih <samimseih@gmail.com>

Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-10-24T05:54:22Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix const correctness in pgstat data serialization callbacks
- 167cb26718e3 19 (unreleased) landed
test_custom_stats: Add tests with read/write of auxiliary data
- 481783e69f14 19 (unreleased) landed
Allow cumulative statistics to read/write auxiliary data from/to disk
- 4ba012a8ed9c 19 (unreleased) landed
test_custom_stats: Test module for custom cumulative statistics
- 31280d96a648 19 (unreleased) landed
injection_points: Remove portions related to custom pgstats
- d52c24b0f808 19 (unreleased) landed
Rename routines for write/read of pgstats file
- ed823da12891 19 (unreleased) landed

On Thu, Oct 23, 2025 at 07:57:38PM -0500, Sami Imseih wrote:
> I was trying to avoid an extra field in PgStat_KindInfo if possible, but
> it's worthwhile to provide more flexibility to an extension. I will go
> with this.

Yes, I don't think that we will be able to avoid some refactoring of
the existing callbacks.  The introduction of a new one may not be
completely necessary, though, especially if we reuse the reset
callback to be called when the stats read and write finish to close
any fds we may have opened when processing.

Maintaining the state of the files opened within each stat kind code
across multiple calls of the new "serialized" callback feels a bit
more natural and more flexible, at least it's my take on the matter.
--
Michael