From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_get_multixact_members not documented |
Date: | 2025-06-11 16:14:12 |
Message-ID: | CAA5RZ0vgJEZTDgVwXmDZVS4CKYoPpNPhzMpyKS7WkvFhEhgAqA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> It's not clear, without some effort, which lock mode go with which row lock in that description.
> For example, "keysh" does not have "for" in it but "fornokeyupd" does. How about rephrasing this
> as "The lock modes "keysh", "sh", fornokeyupd", and "forupd" correspond to
> <literal>FOR KEY SHARE</literal>, <literal>FOR SHARE</literal>, <literal>FOR NO KEY UPDATE</literal>,
> and <literal>FOR UPDATE</literal> row level locks respectively as described in <xref linkend="locking-rows"/>."
That works for me.
> Do we want to add the section "Multixact Information Functions" after other transaction related
> sections like "Transaction ID and Snapshot Information Function" and
> " Committed Transaction Information Functions" instead of adding it at the end?
makes sense.
See v4 which addresses the points above.
--
Sami
Attachment | Content-Type | Size |
---|---|---|
v4-0001-Document-pg_get_multixact_members.patch | application/octet-stream | 3.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Ilia Evdokimov | 2025-06-11 16:36:43 | Performance optimization for ANALYZE with extended statistics (dependencies) |
Previous Message | Florents Tselai | 2025-06-11 16:08:25 | Re: add function for creating/attaching hash table in DSM registry |