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: Chao Li <li.evan.chao@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-12T02:58:54Z
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, Dec 10, 2025 at 12:36:36PM -0600, Sami Imseih wrote:
> .. and after giving this more thought, I actually don't think we should
> do any validation for any of the callbacks. If an extension is writing
> to any file ( core or custom ), naturally they will want to read it back.
> Now I am not sure what these validations are protecting us against.
> Also, maybe the extension wants to just read data from the main stats
> file, I could see that use-case, perhaps.
> 
> So, I am proposing removing the validation altogether. What do
> you think?

The to and from callbacks are coupled with each other, so there may be
a point in making sure that if one is defined so is the other.  Now, I
have never done any enforcement for the existing from/to serialization
callbacks either because it would be quickly clear for one what needs
to be done when implementing a custom kind.  So I'd agree with just
removing these checks and keep the code simpler.

FWIW, I have begun putting my hands on your patch, editing it at some
degree.  I am not sure that I will be able to finish that today, but
I'm working towards getting something done.
--
Michael