Committed.
--
nathan
>> Perhaps we should think about removing this description, what do you think?
> I think it's a good topic for another patch/thread. Chances are it's not
> the only description that could be updated.
Sure, that could be taken up after this patch.
> That's what I mean. I think it should say
>
>
On Mon, Jun 30, 2025 at 02:54:28PM -0500, Nathan Bossart wrote:
> I noticed that this list of exceptions doesn't exist on v13-v15, presumably
> because the docs for age() and mxid_age() were only back-patched to v16
> (see commits 48b5aa3 and 15afb7d), which is strange because I believe those
> fun
On Mon, Jun 30, 2025 at 06:19:10PM +0300, Sami Imseih wrote:
> Perhaps we should think about removing this description, what do you think?
I think it's a good topic for another patch/thread. Chances are it's not
the only description that could be updated.
>> Looking again, pg_get_multixact_membe
> Sure, I am not against keeping the function in an existing section, but
> we should remove the description mentioned above for clarity.
to be clear, I am suggesting we just remove the second sentence
in the description. Therefore, instead of:
"The functions shown in Table 9.84 provide server tr
> On Mon, Jun 30, 2025 at 04:08:04PM +0300, Sami Imseih wrote:
> > Correct, I originally proposed the "Transaction ID and Snapshot
> > Information Functions" section, but as stated in [0],
> > pg_get_multixact_members does not fit the description of the section as
> > it is described as "The main
On Mon, Jun 30, 2025 at 04:08:04PM +0300, Sami Imseih wrote:
> Correct, I originally proposed the "Transaction ID and Snapshot
> Information Functions" section, but as stated in [0],
> pg_get_multixact_members does not fit the description of the section as
> it is described as "The main use of the
On Mon, Jun 30, 2025 at 7:29 AM Ashutosh Bapat
wrote:
>
> On Sat, Jun 28, 2025 at 4:02 AM Nathan Bossart
> wrote:
> >
> > On Thu, Jun 12, 2025 at 03:10:56PM -0500, Nathan Bossart wrote:
> > > Barring comments/objections, I'll plan on committing/back-patching this in
> > > the near future.
> >
>
On Sat, Jun 28, 2025 at 4:02 AM Nathan Bossart wrote:
>
> On Thu, Jun 12, 2025 at 03:10:56PM -0500, Nathan Bossart wrote:
> > Barring comments/objections, I'll plan on committing/back-patching this in
> > the near future.
>
> Here is what I have staged for commit. I ended up moving it to the
> "T
On Thu, Jun 12, 2025 at 03:10:56PM -0500, Nathan Bossart wrote:
> Barring comments/objections, I'll plan on committing/back-patching this in
> the near future.
Here is what I have staged for commit. I ended up moving it to the
"Transaction ID and Snapshot Information Functions" table, which is wh
On Thu, Jun 12, 2025 at 12:15:03AM -0500, Sami Imseih wrote:
>> Attached patch removing extra comma. Otherwise LGTM.
>
> Thanks! For v4, the final comma in the list is grammatically correct,
> and it´s the style we use throughout the docs.
+1
> I marked the patch RFC.
Barring comments/objection
> Attached patch removing extra comma. Otherwise LGTM.
Thanks! For v4, the final comma in the list is grammatically correct,
and it’s the style we use throughout the docs.
I marked the patch RFC.
--
Sami
On Wed, Jun 11, 2025 at 9:44 PM Sami Imseih wrote:
> > 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", fo
> 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
> FOR KEY SHARE, F
On Fri, Jun 6, 2025 at 4:15 AM Sami Imseih wrote:
> > We developers may understand the mode text "sh", "keysh" etc. But it may
> not be user friendly.
>
> yes, I can see that being a point of confusion.
>
> > It would have been better if the function would have reported standard
> modes as descri
Thanks for the review!
> +1. PFA diff of some edits. Please incorporate them in
> your patch if you find them correct.
sure, the diff looks fine to me. will fix.
> We developers may understand the mode text "sh", "keysh" etc. But it may not
> be user friendly.
yes, I can see that being a point
On Thu, Jun 5, 2025 at 2:11 AM Sami Imseih 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
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 becaus
--
Sami Imseih
Amazon Web Services (AWS)
On Mon, Jun 2, 2025 at 3:03 PM Nathan Bossart
wrote:
> On Mon, Jun 02, 2025 at 12:46:51PM -0500, Sami Imseih wrote:
> > v1-0001 is the documentation only patch. I improved upon the description
> > suggested in [0]
>
> Your patch adds an entry to the "Tra
On Mon, Jun 02, 2025 at 12:46:51PM -0500, Sami Imseih wrote:
> v1-0001 is the documentation only patch. I improved upon the description
> suggested in [0]
Your patch adds an entry to the "Transaction ID and Snapshot Information
Functions" table, while Álvaro's introduced a new "Multixact Functions
> > Want to put together a patch?
>
> Yes, will do
v1-0001 is the documentation only patch. I improved upon the description
suggested in [0]
> > For extra credit, maybe we could add a test or two, too...
I can add tests, even though we don't really have system function specific
testing.
A simpl
On Fri, May 30, 2025 at 02:23:30PM -0500, Sami Imseih wrote:
> While looking into another multixact related topic, I realised that
> pg_get_multixact_members
> is not documented. I saw the lack of documentation was mentioned here [0], but
> this was never committed.
>
> Any reason it should not be
On Fri, May 30, 2025 at 04:24:43PM -0500, Sami Imseih wrote:
>> Want to put together a patch?
>
> Yes, will do
For extra credit, maybe we could add a test or two, too...
--
nathan
Thanks!
> blog posts that recommend it. In any case, I can't think of a reason it
> ought to remain undocumented.
I agree, especially with blogs referencing it.
> Want to put together a patch?
Yes, will do
—
Sami
24 matches
Mail list logo
