Re: Add memory_limit_hits to pg_stat_replication_slots

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add memory_limit_hits to pg_stat_replication_slots
Date: 2025-10-07 17:44:33
Message-ID: CAD21AoCY8iot976RkurnWFcDxE7cwt7NaEEdgnec4iF-UJcPyQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 7, 2025 at 1:08 AM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Mon, Oct 06, 2025 at 01:18:38PM -0700, Masahiko Sawada wrote:
> > On Sun, Oct 5, 2025 at 11:52 PM Bertrand Drouvot
> > <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> > >
> > > Could we also imagine that there are other activities enough to reach the memory
> > > limit and transactions are not aborted, meaning spill_txns and/or spill_count are > 0?
> > >
> > > In that case we may want to get rid of this test instead (as checking spill_txns >=0
> > > and spill_count >=0 would not really reflect the intend of this test).
> >
> > It makes sense to me to make an assumption that there are no
> > concurrent activities that are capturable by logical decoding during
> > this test. So I think we don't need to care about that case. On the
> > other hand, under this assumption, it also makes sense to check it
> > with the exact number. I've chosen >0 as we can achieve the same goal
> > while being more flexible for potential future changes. I'm open to
> > other suggestions though.
>
> >0 is fine by me. I was just wondering about spill_txns and spill_count too.
>
> That could sound weird that we are confident for spill_txns and spill_count
> to rely on the exact values and not for the new field. That said, I agree that
> >0 is more flexible for potential future changes (in the sense that this one
> is more likely to change in its implementation). In short, I'm fine with your
> proposal.

Thank you for the comment. I've noted this discussion as a comment in
the new tests.

I've attached the updated version patch. Please review it.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v7-0001-Add-mem_exceeded_count-column-to-pg_stat_replicat.patch application/octet-stream 24.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2025-10-07 17:45:12 Re: Add mode column to pg_stat_progress_vacuum
Previous Message Joel Jacobson 2025-10-07 17:28:22 Re: Optimize LISTEN/NOTIFY