Re: pg_get_multixact_members not documented

On Thu, Jun 5, 2025 at 2:11 AM Sami Imseih <samimseih@gmail.com> wrote:

> v2 addresses the comments.
>
> Adds a new section called "Multixact Information Functions" and a reference
> to pg_get_multixact_members after the description of what multixact members
> are in maintenance.sgml.
>
> As I spent some time looking into this, I still think we should document
> this
> function because of its use in blogs and examples that describe multixact.
>

+1. PFA diff of some edits. Please incorporate them in your patch if you
find them correct.

The table description from Alvaro's patch is better. The change is included
in the diff.

We developers may understand the mode text "sh", "keysh" etc. But it may
not be user friendly. It would have been better if the function would
have reported standard modes as described in [1] but we can't change that
now. It might help if we add mapping in the documentation.



"" ... each member of the multixact identified by the given mxid' sounds
more accurate compared to " ... each member of a given multixact ID". That
document page seems to differentiate between a transaction and transaction
ID. I think we should try to do the same for multixact.

>
> However, this function does not appear to be very practical to use, because
> the only visible MXID to the user is the oldest one, via
> pg_database.datminmxid
> or pg_class.relfrozenxid, or with the help of the contrib extension
> pgrowlocks.
>

If somebody starts from a row itself e.g. select xmax, * from t1 ... , this
function gives the transactions that have locked a given row. So not that
useless.


> I really think this is an area that needs improvement. We tell users to
> ignore
> transactions that have "no chance" of appearing in a multixact, but what
> that
> really means is the user must somehow figure this out on their own. I don't
> think it would be unrealistic to expose real-time information about
> backends
> with transactions involved in multixacts.
>

+1. Multixacts are highly under documented in user facing as well as
internal documentations. Thanks for the patch.

[1]
https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-TABLES
-- 
Best Wishes,
Ashutosh Bapat