Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Naga Appani <nagnrik@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>, pgsql-hackers@postgresql.org
Date: 2025-08-19T06:32:19Z
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 →
-
Add pg_get_multixact_stats()
- 97b101776ce2 19 (unreleased) landed
-
Add MultiXactOffsetStorageSize() to multixact_internal.h
- 0e3ad4b96aed 19 (unreleased) landed
-
Change GetMultiXactInfo() to return the next multixact offset
- 9cf746a453c1 19 (unreleased) landed
-
Widen MultiXactOffset to 64 bits
- bd8d9c9bdfa0 19 (unreleased) cited
-
Refactor ReadMultiXactCounts() into GetMultiXactInfo()
- a977e419ee6e 19 (unreleased) landed
-
Move SQL-callable code related to multixacts into its own file
- df9133fa6384 19 (unreleased) landed
-
Split func.sgml into more manageable pieces
- 4e23c9ef65ac 19 (unreleased) cited
On Mon, Aug 18, 2025 at 08:32:39PM -0500, Naga Appani wrote: > Thanks a lot for taking the time to review this patch and share your thoughts. > > Here’s a short summary of what has changed in v5: > - Added the new pg_get_multixact_stats() function in multixactfuncs.c. > - Fixed the misleading “atomic read” comment in the accessor. > - Clarified documentation: thresholds are described in terms of > counts, since that’s what the code uses. > - Added a members_bytes column in pg_get_multixact_stats() to give > users a rough size estimate (num_members * 5), while making it clear > this is layout-dependent. > > Please see my in-line replies below. FWIW, I think that you should be a bit more careful before sending updated patch sets. You have missed an extra point I have raised upthread about the refactoring pieces: the switch from ReadMultiXactCounts() to GetMultiXactInfo() can be done in a patch of its own. So I have extracted this part from your latest patch, and applied it independently of the SQL function business. Now we are in an advantageous position on HEAD: even if we do not conclude about the SQL function to show the mxact numbers and offsets, we have the function that gives an access to the data you are looking for. In short, it is now possible to provide an equivalent of the feature you want outside of core. Not saying that the patch cannot be useful, but such refactoring pieces open more possibilities, and offer a cleaner commit history with less churn in the main patches. -- Michael