Re: pg_get_multixact_members not documented

> On Mon, Jun 30, 2025 at 04:08:04PM +0300, Sami Imseih wrote:
> > Correct, I originally proposed the "Transaction ID and Snapshot
> > Information Functions" section, but as stated in [0],
> > pg_get_multixact_members does not fit the description of the section as
> > it is described as "The main use of these functions is to determine
> > which transactions were committed between two snapshots."
>
> Well, is that description correct? I've used several of these functions,
> but I'm not sure I've ever used them for this purpose.

I suppose the description is not applicable to all of these functions;
for example
pg_current_xact_id_if_assigned() returns the current transactions xid, so the
description does not apply. Neither does it apply to pg_snapshot_xip().

this description has been around since 8.3 from what I can tell, and
when the inventory
of functions in this section was much smaller and most required a snapshot as an
argument.

Perhaps we should think about removing this description, what do you think?

> Looking again, pg_get_multixact_members() might need to be added to this
> list of exceptions:
>
> However, the functions shown in Table 9.84, except age and mxid_age,
> use a 64-bit type xid8 that does not wrap around during the life of an
> installation and can be converted to xid by casting if required; see
> Section 67.1 for details.

This function returns an xid and not an int8 such as for example
```
{ oid => '3819', descr => 'view members of a multixactid',
proname => 'pg_get_multixact_members', prorows => '1000', proretset => 't',
provolatile => 'v', prorettype => 'record', proargtypes => 'xid',
proallargtypes => '{xid,xid,text}', proargmodes => '{i,o,o}',
proargnames => '{multixid,xid,mode}', prosrc => 'pg_get_multixact_members' },
```
```
{ oid => '2943', descr => 'get current transaction ID',
proname => 'txid_current', provolatile => 's', proparallel => 'u',
prorettype => 'int8', proargtypes => '', prosrc => 'pg_current_xact_id' },
```
am I missing something?

> I'm also a little wary of adding a new section on the back-branches because
> it will change some section numbers.

Sure, I am not against keeping the function in an existing section, but
we should remove the description mentioned above for clarity.

--
Sami