Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 8 Aug 2025 09:35:52 +0900
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
Subject: Re: [Proposal] Expose internal MultiXact member count function for
 efficient monitoring
Message-ID: <aJVGaHjKsz1BfJ5B@paquier.xyz>
References: 
 <CA+QeY+AAsYK6WvBW4qYzHz4bahHycDAY_q5ECmHkEV_eB9ckzg@mail.gmail.com>
 <CA+QeY+CuTcKSFmw3H-_OtCv+bv0T4uTSFgaAY1N9ssL-WaiiSA@mail.gmail.com>
 <CALdSSPi3Gh08NtcCn44uVeUAYGOT74sU6uei_06qUTa5rMK43g@mail.gmail.com>
 <CA+QeY+DTggHskCXOa39nag2sFds9BD-7k__zPbvL-_VVyJw7Sg@mail.gmail.com>
 <CAExHW5uxBnodmpXygUQUxZAyxYvbXczadxGOVeL=0DxpkXUR-g@mail.gmail.com>
 <aIb67MiYhVy7gwV-@paquier.xyz>
 <CAExHW5vba_ecL2c27giAOOaRxoNdVX2BNQVCN4PFOZJC17NrqQ@mail.gmail.com>
 <CA+QeY+CFLjh0gb-j9p+0eJK=r19izhEPCBY3ns4+HCgOQojh8Q@mail.gmail.com>
 <CA+QeY+D_npapLjsu0UZ-pgRGLwqx0GjAmRL_a+R9UOB7jgY=_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="DSmitDN0SMmCWxZA"
Content-Disposition: inline
In-Reply-To: 
 <CA+QeY+D_npapLjsu0UZ-pgRGLwqx0GjAmRL_a+R9UOB7jgY=_Q@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aJVGaHjKsz1BfJ5B%40paquier.xyz>
Precedence: bulk


--DSmitDN0SMmCWxZA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 04, 2025 at 04:51:30PM -0500, Naga Appani wrote:
> The rest of the patch remains the same as v2, which incorporated
> feedback from Ashutosh and Michael (see my previous email for
> details).
>=20
> Please find v3 attached.

I am reading again what you have here, and I really think that we
should move the SQL function parts of multixact.c into their own new
file, exposing ReadMultiXactCounts() in multixact.h, because I also
suspect that this can become really useful for extensions that aim at
doing things similar to your proposal in terms of data monitoring for
autovacuum wraparound.  This means two refactoring patches:
- One to expose the new routine in multixact.h.
- One to move the existing SQL code to its new file.=20

ReadMultiXactCounts() is also incorrectly named with your proposal to
expose oldestMultiXactId in the information returned to the caller,
where the key point is to make sure that the information retrieved is
consistent across a single LWLock acquisition.  So perhaps this should
be named GetMultiXactInformation() or something similar?

The top of ReadMultiXactCounts() (or whatever its new name) should
also document the information returned across a single call.  It looks
inconsistent to return oldestMultiXactId if the oldestOffsetKnown is
false.  What about oldestOffset itself?  Should it be returned for
consistency with the counts and oldestMultiXactId?
--
Michael

--DSmitDN0SMmCWxZA
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmiVRmgACgkQnvQgOdby
QH0vCw//RhmISJgx0NTKbnJK4wQV8huysWR6wTpu+4r5RGVqBHuelkGTvnFT7XS9
NL1QqKe0lNACtqTWysXOnYv4Kh+TgMP2OUy1p5L2cPciprdfc23Q/QFOGSWbl05U
GQDkELfY5w73ksY3h1SZ/8TijDdTuf2JqYMCjhTrN1D30Meyl201FdrRzY69OKaj
zYCBWs9/IUHXbR66dS6xcFXCIs2bNM0MPHyRA3YlVbzkTC1SeUIB32bLZ4HCEVmD
RzrNGZ19cT3DeAhg7u+CBDfp9+bvmUrQI6Co3W38zMbrt5J+RiJI3cM/vopY8ZdE
GEFIUJrEvmCqedvVIJkQqkftItQIuzdS1E0CXdyBFfUwi2gbX0CRSjKdRrsrgx9r
nx7A/ouJjMRXV5SYeAraMVJUGqLwamWUdfleaIH9WKD03Upr+NsXswD5mffM+zZK
yHbO1nsX4Gb944cchVAAgsPvbIzC4vJMvJBDzUsMGb/Pq0+Zm70VPSQdfbmq0BAJ
WRCkZevHpckEiTcKzvkLl54hxhQYPKlNKoxwKhw/QQUqKnmsGy8NbXk6xh+HwwV9
fn2F2mGUMgAO6zhletFfoP7WSmVqLg7rxSqoBUIPg7RR4COYZUsrNXUtZlibmDyB
Vl7p0cCpqJxN4ISsRO4bq6aG2sW2RKqtk1Wx9pdApylfXIZs/f4=
=jmIT
-----END PGP SIGNATURE-----

--DSmitDN0SMmCWxZA--