Hi Ashutosh,
Thank you for continuing to review the patch. Attached is v9,
incorporating the feedback. Please see my responses inline below.
On Fri, Sep 12, 2025 at 5:34 AM Ashutosh Bapat
wrote:
> + Returns statistics about current multixact usage:
> + num_mxids is the total number of multixact
On Fri, Sep 12, 2025 at 9:03 AM Naga Appani wrote:
>
+
+
+ Returns statistics about current multixact usage:
+ num_mxids is the total number of multixact IDs
assigned since startup,
+ num_members is the total number of multixact
member entries created since startup,
GetMultiXactInfo() returns
Hi Ashutosh,
Thank you for continuing to review the patch. Attached is v8,
incorporating the feedback. Please see my responses inline below.
On Fri, Sep 5, 2025 at 6:27 AM Ashutosh Bapat
wrote:
>
> This one is remaining.
> + up to approximately 2^32 entries before reaching wraparound.
>
> ... 2^
On Thu, Sep 4, 2025 at 2:41 AM Naga Appani wrote:
>
> On Fri, Aug 22, 2025 at 6:45 AM Ashutosh Bapat
> wrote:
> >
> > On Fri, Aug 22, 2025 at 7:37 AM torikoshia
> > wrote:
> > >
> Updated docs to include both counts and approximate storage.
>
This one is remaining.
+ up to approximately 2^32 e
Hi Atsushi and Ashutosh,
Thank you for reviewing the patch. Attached is v7, incorporating the
feedback. Please see my responses in-line below.
On Fri, Aug 22, 2025 at 6:45 AM Ashutosh Bapat
wrote:
>
> On Fri, Aug 22, 2025 at 7:37 AM torikoshia wrote:
> >
> > | Now that pg_get_multixact_stats()
On Fri, Aug 22, 2025 at 7:37 AM torikoshia wrote:
>
> | Now that pg_get_multixact_stats() exposes num_members, the HEAD branch
> | docs can describe the thresholds in terms of counts directly.
>
> Personally, I think it might be fine to keep the gigabyte-based
> description, and perhaps we could s
On 2025-08-22 09:28, torikoshia wrote:
On 2025-08-20 13:27, Naga Appani wrote:
Thanks for working on this!
On Tue, Aug 19, 2025 at 1:32 AM Michael Paquier
wrote:
FWIW, I think that you should be a bit more careful before sending
updated patch sets. You have missed an extra point I have rais
On 2025-08-20 13:27, Naga Appani wrote:
Thanks for working on this!
On Tue, Aug 19, 2025 at 1:32 AM Michael Paquier
wrote:
FWIW, I think that you should be a bit more careful before sending
updated patch sets. You have missed an extra point I have raised
upthread about the refactoring pieces
On Tue, Aug 19, 2025 at 1:32 AM Michael Paquier wrote:
> FWIW, I think that you should be a bit more careful before sending
> updated patch sets. You have missed an extra point I have raised
> upthread about the refactoring pieces: the switch from
> ReadMultiXactCounts() to GetMultiXactInfo() can
On Mon, Aug 18, 2025 at 08:32:39PM -0500, Naga Appani wrote:
> Thanks a lot for taking the time to review this patch and share your thoughts.
>
> Here’s a short summary of what has changed in v5:
> - Added the new pg_get_multixact_stats() function in multixactfuncs.c.
> - Fixed the misleading “ato
Hi Michael, Ashutosh,
Thanks a lot for taking the time to review this patch and share your thoughts.
Here’s a short summary of what has changed in v5:
- Added the new pg_get_multixact_stats() function in multixactfuncs.c.
- Fixed the misleading “atomic read” comment in the accessor.
- Clarified d
On Sun, Aug 17, 2025 at 11:57 AM Naga Appani wrote:
> On Fri, Aug 8, 2025 at 4:33 AM Ashutosh Bapat
> wrote:
>
> > In case each member starts consuming more or less space than it does
> > today what would be the basis of triggering wraparound? Space or
> > number of members? I think we should me
On Sun, Aug 17, 2025 at 01:27:29AM -0500, Naga Appani wrote:
> On Thu, Aug 7, 2025 at 7:35 PM Michael Paquier wrote:
>>
>> I really think that we should move the SQL function parts of multixact.c
>> into their own new file, exposing ReadMultiXactCounts() in multixact.h...
>
> Done. The SQL-callab
Hi Michael, Ashutosh,
Thanks a lot for the detailed reviews and feedback. Please find
attached v4 of the patchset.
Summary of changes in v4:
- Split into two patches as suggested:
1. Expose and rename ReadMultiXactCounts() -> GetMultiXactInfo() in
multixact.h with clearer comments.
2. Add pg_
On Mon, Aug 4, 2025 at 11:46 AM Naga Appani wrote:
> > In PG14+, the transaction wraparound is triggered if the size of the
> > directory exceeds 10GB. This function does not help monitoring that
> > condition. So a user will need to use du or pg_ls_multixactdir()
> > anyway, which defeats the pur
On Mon, Aug 04, 2025 at 04:51:30PM -0500, Naga Appani wrote:
> The rest of the patch remains the same as v2, which incorporated
> feedback from Ashutosh and Michael (see my previous email for
> details).
>
> Please find v3 attached.
I am reading again what you have here, and I really think that w
On Mon, Aug 4, 2025 at 1:16 AM Naga Appani wrote:
>
> Hi Ashutosh, Michael,
>
> Thanks for the detailed reviews. I have incorporated the feedback;
> please find attached v2 and my responses inline below.
>
> On Fri, Jul 25, 2025 at 5:57 AM Ashutosh Bapat
> wrote:
>
> > In [1], we decided to docum
Hi Ashutosh, Michael,
Thanks for the detailed reviews. I have incorporated the feedback;
please find attached v2 and my responses inline below.
On Fri, Jul 25, 2025 at 5:57 AM Ashutosh Bapat
wrote:
> In [1], we decided to document pg_get_multixact_member() in section
> "Transaction ID and Snaps
On Mon, Jul 28, 2025 at 9:52 AM Michael Paquier wrote:
>
> May I also suggest a split of the multixact SQL functions into a
> separate file, a src/backend/utils/adt/multixactfuncs.c? The existing
> pg_get_multixact_members() relies on GetMultiXactIdMembers(),
> available in multixact.h. The new
On Fri, Jul 25, 2025 at 04:27:37PM +0530, Ashutosh Bapat wrote:
> In [1], we decided to document pg_get_multixact_member() in section
> "Transaction ID and Snapshot Information Functions". I think the
> discussion in the email thread applies to this function as well.
Yep, let's be consistent.
> T
On Tue, Jun 10, 2025 at 7:50 PM Naga Appani wrote:
>
> On Tue, Mar 11, 2025 at 4:48 AM Kirill Reshke wrote:
> >
> > On Tue, 11 Mar 2025 at 14:37, Naga Appani wrote:
> > >
> > >
> > >
> > > On Mon, Mar 10, 2025 at 10:43 AM Naga Appani wrote:
> > >>
> > >> Hi,
> > >>
> >
> > Hi
> >
> > >
On Tue, Mar 11, 2025 at 4:48 AM Kirill Reshke wrote:
>
> On Tue, 11 Mar 2025 at 14:37, Naga Appani wrote:
> >
> >
> >
> > On Mon, Mar 10, 2025 at 10:43 AM Naga Appani wrote:
> >>
> >> Hi,
> >>
>
> Hi
>
> > =
> > Proposal
> > =
> > The internal ReadMultiXactCounts(
On Mon, Mar 10, 2025 at 10:43 AM Naga Appani wrote:
> Hi,
>
> I would like to propose exposing an internal PostgreSQL function called
> ReadMultiXactCounts() to allow for efficient monitoring of MultiXact
> member usage. This function provides an accurate, real-time view of
> MultiXact activity b
On Tue, 11 Mar 2025 at 14:37, Naga Appani wrote:
>
>
>
> On Mon, Mar 10, 2025 at 10:43 AM Naga Appani wrote:
>>
>> Hi,
>>
Hi
> =
> Proposal
> =
> The internal ReadMultiXactCounts() function, implemented in multixact.c,
> directly calculates the number of MultiXa
Hi,
I would like to propose exposing an internal PostgreSQL function called
ReadMultiXactCounts() to allow for efficient monitoring of MultiXact member
usage. This function provides an accurate, real-time view of MultiXact
activity by directly retrieving the actual member count, rather than
relyin
25 matches
Mail list logo
