On Thu, Jun 5, 2025 at 2:11 AM Sami Imseih <samims...@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
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 5c6a8b3b3db..831f878e463 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -28501,7 +28501,7 @@ acl | {postgres=arwdDxtm/postgres,foo=r/postgres}
<para>
The functions shown in <xref linkend="functions-multixact"/>
- provide information about about current Multixact usage.
+ provide information about multixacts in the system.
</para>
<table id="functions-multixact">
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index a21b42a6bd3..94f75f3da8f 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -779,7 +779,7 @@ HINT: Execute a database-wide VACUUM in that database.
careful aging management, storage cleanup, and wraparound handling.
There is a separate storage area which holds the list of members in
each multixact, which also uses a 32-bit counter and which must also
- be managed. The system function
<function>pg_get_multixact_members</function>
+ be managed. The system function
<function>pg_get_multixact_members()</function>
described in <xref linkend="functions-info-multixact"/> can be used to
examine the transaction IDs associated with a multixact ID.
</para>
