Re: Add memory_limit_hits to pg_stat_replication_slots
От | Bertrand Drouvot |
---|---|
Тема | Re: Add memory_limit_hits to pg_stat_replication_slots |
Дата | |
Msg-id | aOTKkKasgzCbvGDl@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
Ответ на | Re: Add memory_limit_hits to pg_stat_replication_slots (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Add memory_limit_hits to pg_stat_replication_slots
|
Список | pgsql-hackers |
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.pg@gmail.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. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: