Thanks for the suggestion and review, Michael and Ashutosh! On Tue, Dec 16, 2025 at 11:17 PM Ashutosh Bapat <[email protected]> wrote: > > On Wed, Dec 17, 2025 at 9:49 AM Michael Paquier <[email protected]> wrote: > > > > On Sat, Dec 13, 2025 at 01:34:47PM -0600, Naga Appani wrote: > > > > > > I validated the behavior before and after cleanup. > > > The function correctly reports current usage (beyond the old limits) and > > > resets once multixacts are removed: > > > > + /* > > + * Calculate storage space for members. Members are stored in > > groups, > > + * with each group containing MULTIXACT_MEMBERS_PER_MEMBERGROUP > > members > > + * and taking MULTIXACT_MEMBERGROUP_SIZE bytes. > > + */ > > + membersBytes = (int64) (members / > > MULTIXACT_MEMBERS_PER_MEMBERGROUP) * > > + MULTIXACT_MEMBERGROUP_SIZE; > > > > This is the key point of the patch internal logic. And there is one > > thing that I am wondering here. The amount of space taken by a number > > of members depends on the other compiled constants from > > multixact_internal.h. Hence, rather than calculate the amount of > > space taken by a set of members in some code hidden in the SQL > > function, could it be better to put that directly as a macro or an > > inline function in multixact_internal.h? > > +1. > > -- > Best Wishes, > Ashutosh Bapat
I’ve updated the patch as suggested. The member storage size calculation has been refactored into a static inline function, MultiXactMemberStorageSize(), in src/include/access/multixact_internal.h. Please find v13 attached. Regards, Naga
v13-0001-Add-pg_get_multixact_stats-function-for-monitori.patch
Description: Binary data
