Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Naga Appani <nagnrik(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
Date: 2025-12-25 01:30:37
Message-ID: aUyTvZMq2CLgNEB4@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 25, 2025 at 09:45:33AM +0900, Michael Paquier wrote:
> Seems basically sensible here for the structure, including the hints
> and recommendations for the GUCs.

+/* Calculate storage space in bytes for a given number of members */
+static inline int64
+MultiXactMemberStorageSize(MultiXactOffset members)
+{
+ return (int64) (members / MULTIXACT_MEMBERS_PER_MEMBERGROUP) *
+ MULTIXACT_MEMBERGROUP_SIZE;
+}

By the way, this bit also feels a bit confusing, and this comes down
to the fact that "members" is not an offset, isn't it? This relates
to MultiXactMemberFreezeThreshold(), that considers the number of
members as an offset, but it is a number of members, a difference
between two offsets.

I am wondering if it would not be cleaner and less confusing to do
things slightly differently (sorry I did not pay much attention to
that previously):
- Change GetMultiXactInfo() to return two offsets, nextOffset and
oldestOffset.
- Use uint64 for members and recalculate the difference in
MultiXactMemberFreezeThreshold() and the function code. Heikki has
just switched multixact offsets to be 64 bits, yippee.
- Redefine MultiXactMemberStorageSize() so as it does not take a
number of members in input, but as the amount of space taken between
two offsets. At least that would be more consistent with all the
other inline functions of multixact.h that rely on MultiXactOffset
inputs. Using a int64 is still OK I guess, there may be a case to
detect "negative" numbers and give a change to the users of the new
inline function to notice that they did a computation wrong, rather
than hiding a signedness problem.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-12-25 01:50:16 Re: Resetting recovery target parameters in pg_createsubscriber
Previous Message Dharin Shah 2025-12-25 00:54:46 Re: Fwd: [PATCH] Add zstd compression for TOAST using extended header format