Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 17 Dec 2025 13:19:11 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Naga Appani <nagnrik@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
	Tomas Vondra <tomas@vondra.me>, Xuneng Zhou <xunengzhou@gmail.com>,
	torikoshia <torikoshia@oss.nttdata.com>,
	Kirill Reshke <reshkekirill@gmail.com>,
	pgsql-hackers@postgresql.org
Subject: Re: [Proposal] Expose internal MultiXact member count function for
 efficient monitoring
Message-ID: <aUIvP9iZ1F6VSOYp@paquier.xyz>
References: 
 <CAExHW5sFtNduYEnyGhQOb=xiLrbkvwE0merhpZA5pNqcNzBbmw@mail.gmail.com>
 <CA+QeY+C38cgqesZi1Tt92=D6rw_RzCV5yKhoDe5eFLtQ9RQB_Q@mail.gmail.com>
 <29f9e7abc90c3a4fe4a44026141c0d6c@oss.nttdata.com>
 <CABPTF7WfTDdhZbHBgoqo=uGP_DZO-xO1bX5BfkwjgHK9jU+tOA@mail.gmail.com>
 <95850ce1-2d5e-4271-92ea-c2a02e36b303@vondra.me>
 <CA+QeY+Aja_=j1EuY87L06KaPO4EJqqkS4B+Vg9AsWnGM1d_VRA@mail.gmail.com>
 <CAExHW5vDJ526OXv+Hk-=TxPoiL7RR+k+xSF2tyNqtaJHC5aoDQ@mail.gmail.com>
 <CA+QeY+CF2q2M51k5t4rZZ2SNeEq8ORf3Dr8T1+jm72VsHRJfjw@mail.gmail.com>
 <CAExHW5shToKbeiw1eRGeiSyVeCYZUJyw2KUtBKYFn0J3dCGzbA@mail.gmail.com>
 <CA+QeY+CqRjUj93_kV0YmMBqfkgo4WGEoiYOaP_wCMoJ8FOKpog@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Nph+9U8F3Ih8joUd"
Content-Disposition: inline
In-Reply-To: 
 <CA+QeY+CqRjUj93_kV0YmMBqfkgo4WGEoiYOaP_wCMoJ8FOKpog@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aUIvP9iZ1F6VSOYp%40paquier.xyz>
Precedence: bulk


--Nph+9U8F3Ih8joUd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 13, 2025 at 01:34:47PM -0600, Naga Appani wrote:
> Documentation changes:
> - Removed the NULL-return discussion from func-info.sgml, as the
>   statistics are now always available.
> - Updated maintenance.sgml to clarify that exceeding the historical
>   2^32 member limit no longer causes wraparound, but instead triggers
>   more aggressive vacuum activity for disk space management.
>=20
> 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 =3D (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?
--
Michael

--Nph+9U8F3Ih8joUd
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmlCLz8ACgkQnvQgOdby
QH2n6g//bly+0lUwTrc/iGg9+2+014RN3J1FuVF/GwB4pD9ZyyrGAxn5tm7++0JI
LrYZiKUddFXpM2+3Sa/CikOCiV2U4R+36fDhUmDeQtatUno+onxtfi+8c10TNai/
N4LOmqZwzfu9WAg7hxKqS15Q0hg/KIzLJkbU4jL7CKJaV0Gn1a0jZwa1AhakB1Uz
R2CygBdkgsfh2Zp8VngOB2ds+AIldHMBOZ5Za4+iS6QEk0g4yIaR6TreFk1LD5Ek
yfo5xNSFMSeXJipT/lYMYIPYsxLKS0ylQz+VAV5VUwtdv5djS0PeLmwPT79ENCCP
tTWp0aQoSm7qgb3xkwHwGB/fZYn91XiEbq04K7O4/zE7zzIb7JV0AurSyKZEuNHN
w6y+EcO+iPK9B668Yhy2piiKaJG/iYbKVWHxcBrHjOlTIz9bAK98uBcUkJ3LVO0k
e+yyD0o8JEWeUPXg1/Z9KUAtOaOJBy4/PSP1d2KyjZZctjHIHByCEFkgFcRsyIZV
g+qii9TJ8JWPEoku0UpXUkGQpqLpTAkTKM9Q8lwEvYZPRcM+K4zJi3cO8TdKoxc5
Q1aOgpaE63bjq1jvaM4+itMo4E5LBi6c1W0PNEHaRqg7VIL2wUzZYGr3AVK5qz9J
8YuU36qgSdhKvKYfRDsEYo/V+TlWGi11gswHOFDHgCY8Q07hYew=
=pAIc
-----END PGP SIGNATURE-----

--Nph+9U8F3Ih8joUd--