Horton

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

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Sami Imseih <samimseih@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-24T00:10:29Z
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 →

  1. Fix const correctness in pgstat data serialization callbacks

  2. test_custom_stats: Add tests with read/write of auxiliary data

  3. Allow cumulative statistics to read/write auxiliary data from/to disk

  4. test_custom_stats: Test module for custom cumulative statistics

  5. injection_points: Remove portions related to custom pgstats

  6. Rename routines for write/read of pgstats file

On Wed, Nov 19, 2025 at 08:10:43PM -0600, Sami Imseih wrote:
> It just occurred to me that the documentation [0] should be
> updated to describe the callbacks. I will do that in the next
> revision.
> 
> [0] https://www.postgresql.org/docs/current/xfunc-c.html#XFUNC-ADDIN-CUSTOM-CUMULATIVE-STATISTICS

Hmm.  Based on what I can read from the patch, you are still enforcing
file name patterns in the backend, as of:
+          extra->statfiles[i] = psprintf("%s/pgstat.%d.%d.stat",
+                        PGSTAT_STAT_PERMANENT_DIRECTORY, kind, i);

My take (also mentioned upthread) is that this design should go the
other way around, where modules have the possibility to define their
own file names, and some of them could be generated on-the-fly when
writing the files, for example for a per-file database split, or the
object ID itself.

The important part for variable-numbered stats is that the keys of the
entries have to be in the main pgstats file.  Then, the extra data is
loaded back based on the data in the entry key, based on a file name
that only a custom stats kind knows about (fd and file name).  It
means that the custom stats kind needs to track the files it has to
clean up by itself in this scheme.  We could pass back to the startup
process some fds that it cleans up, but it feels simpler here to let
the custom code do what they want, instead, rather than having an
array that tracks the file names and/or their fds.
--
Michael