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-15T00:55:43Z
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 Sat, Dec 13, 2025 at 06:33:41PM -0600, Sami Imseih wrote:
> I just remembered that we should document the new callbacks in [0] with a
> brief explanation of their purpose and a reference to test_custom_stats
> as an example of usage. What do you think?

I'd rather keep the documentation simpler, pointing only to the
code templates we have and pgstat_internal.h.  One reason is that code
in the documentation tends to rot very easily, particularly when
applied to plugin APIs.  If you think that some of the callbacks of
pgstat_internal.h deserve more documentation or explanation, let's do
that directly in the header.

Saying that, I have tweaked a bit more the patch this morning and
applied the result after splitting things in two: one for the core
backend changes and one for the tests of the new APIs.  Some comments
and error strings have been simplified and I have noticed some more
inconsistencies after a follow-up read.

Another thing that I did not like is the use of "long" for the offset,
which is not portable.  We have a drop-in portable replacement for
seeks and offsets: fseeko() and pgoff_t.  That was in the test code,
but still let's keep things more portable in the long run without a
4-byte limitation on WIN32.

I guess that we are done for this thread then.
--
Michael