Re: Add memory_limit_hits to pg_stat_replication_slots - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Add memory_limit_hits to pg_stat_replication_slots
Date
Msg-id CAD21AoANgpGCJjUYTnmn4MwBhU8ss_mKyOsBgDEh8RBGkBP8rQ@mail.gmail.com
Whole thread Raw
In response to Re: Add memory_limit_hits to pg_stat_replication_slots  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
List pgsql-hackers
On Fri, Oct 3, 2025 at 6:15 AM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> Hi,
>
> On Fri, Oct 03, 2025 at 05:19:42PM +0530, Ashutosh Bapat wrote:
> > + bool memory_limit_reached = (rb->size >= logical_decoding_work_mem *
> > (Size) 1024);
> > +
> > + if (memory_limit_reached)
> > + rb->memExceededCount += 1;
>
> Thanks for looking at it!

+1

> > -SELECT slot_name, spill_txns, spill_count FROM
> > pg_stat_replication_slots WHERE slot_name =
> > 'regression_slot_stats4_twophase';
> > -            slot_name            | spill_txns | spill_count
> > ----------------------------------+------------+-------------
> > - regression_slot_stats4_twophase |          0 |           0
> > +SELECT slot_name, spill_txns, spill_count, mem_exceeded_count FROM
> > pg_stat_replication_slots WHERE slot_name =
> > 'regression_slot_stats4_twophase';
> > +            slot_name            | spill_txns | spill_count |
> > mem_exceeded_count
> > +---------------------------------+------------+-------------+--------------------
> > + regression_slot_stats4_twophase |          0 |           0 |
> >          1
> >  (1 row)
> >
> > Are we sure that mem_exceeded_count will always be 1 in this case? Can
> > it be 2 or more because of background activity?
>
> I think that the question could be the same for spill_txns and spill_count. It
> seems to have been working fine (that way) since this test exists (added in
> 072ee847ad4c) but I think that you raised a good point.
>
> Sawada-San, what do you think about this particular test, is it safe to rely
> on the exact values here?

In short, I'm fine with the change proposed by Ashtosh. I believe that
in this case it's safe to rely on the exact values in principle since
once we reach the memory limit we truncate all changes in the
transaction and skip further changes. This test with the patch fails
if there are other activities enough to reach the memory limit and
those transactions are aborted, which it's unlikely to happen, I
guess. That being said, there is no downside if we check
'mem_exceeded_count > 0' instead of checking the exact number and it
seems more stable for future changes.

Regards,

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



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Add memory_limit_hits to pg_stat_replication_slots
Next
From: Neeraj Shah
Date:
Subject: Re: pg_createsubscriber --dry-run logging concerns