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.
