On Fri, Jul 25, 2025 at 04:27:37PM +0530, Ashutosh Bapat wrote: > In [1], we decided to document pg_get_multixact_member() in section > "Transaction ID and Snapshot Information Functions". I think the > discussion in the email thread applies to this function as well.
Yep, let's be consistent. > Throwing an error causes the surrounding transaction to abort, so it > should be avoided in a monitoring/reporting function if possible. In > this case for example, we could throw a warning instead or report NULL > values. Most likely returning NULL is the best thing we can do, as a safe fallback. > The patch needs tests. Indeed. May I also suggest a split of the multixact SQL functions into a separate file, a src/backend/utils/adt/multixactfuncs.c? The existing pg_get_multixact_members() relies on GetMultiXactIdMembers(), available in multixact.h. The new function pg_get_multixact_count() relies on ReadMultiXactCounts(), which would mean adding it in multixact.h. Even if we finish without an agreement about the SQL function and the end, publishing ReadMultiXactCounts() would give an access to the internals to external code. +PG_FUNCTION_INFO_V1(pg_get_multixact_count); There should be no need for that, pg_proc.dat handling the declaration AFAIK. FWIW, these functions are always kind of hard to use for the end-user without proper documentation. You may want to add an example of how one can use it for monitoring in the docs. -- Michael
signature.asc
Description: PGP signature
