Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
От | Michael Paquier |
---|---|
Тема | Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring |
Дата | |
Msg-id | aKLNBdQc-tCFMszs@paquier.xyz обсуждение исходный текст |
Ответ на | Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring (Naga Appani <nagnrik@gmail.com>) |
Список | pgsql-hackers |
On Sun, Aug 17, 2025 at 01:27:29AM -0500, Naga Appani wrote: > On Thu, Aug 7, 2025 at 7:35 PM Michael Paquier <michael@paquier.xyz> wrote: >> >> I really think that we should move the SQL function parts of multixact.c >> into their own new file, exposing ReadMultiXactCounts() in multixact.h... > > Done. The SQL-callable code now lives in > src/backend/utils/adt/multixactfuncs.c > and the accessor is declared in > src/include/access/multixact.h. My point was a bit different: multixactfuncs.c should be created first because we already have one SQL function in multixact.c that can be moved inside it, with the declarations it requires added to multixact.h. I've extracted what you did, moved the existing pg_get_multixact_members() inside the new file, and applied the result. >> ReadMultiXactCounts() is also incorrectly named with your proposal to >> expose oldestMultiXactId in the information returned to the caller... >> So perhaps this should be named GetMultiXactInformation() or something >> similar? > > Renamed to GetMultiXactInfo(). + * Returns information about current MultiXact state in a single atomic read: This comment is incorrect. This is not an atomic read, grabbing a consistent state of the data across one single lock acquisition. Except for this comment, this looks pretty much OK. Ashutosh, any comments? I have not looked at the rest. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: