| 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: | Whole Thread | Raw Message | 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 |