Re: Add memory_limit_hits to pg_stat_replication_slots
От | shveta malik |
---|---|
Тема | Re: Add memory_limit_hits to pg_stat_replication_slots |
Дата | |
Msg-id | CAJpy0uBskXMq65rvWm8a-KR7cSb_sZH9CPRCnWAQrTOF5fciGw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add memory_limit_hits to pg_stat_replication_slots (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Add memory_limit_hits to pg_stat_replication_slots
|
Список | pgsql-hackers |
On Mon, Sep 22, 2025 at 4:35 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Mon, Sep 22, 2025 at 1:41 PM Bertrand Drouvot > <bertranddrouvot.pg@gmail.com> wrote: > > > > > > > > Since other statistics counter names are camel cases I think it's > > > better to follow that for the new counter. > > > > Makes sense, done with memoryLimitHits in v2 attached (that's the only change > > as compared with v1). > > > > The memory_limit_hits doesn't go well with the other names in the > view. Can we consider memory_exceeded_count? I find > memory_exceeded_count (or memory_exceeds_count) more clear and > matching with the existing counters. Also, how about keeping it > immediately after slot_name in the view? Keeping it in the end after > total_bytes seems out of place. > Since fields like spill_txns, spill_bytes, and stream_txns also talk about exceeding 'logical_decoding_work_mem', my preference would be to place this new field immediately after these spill and stream fields (and before total_bytes). If not this, then as Amit suggested, immediately before all these fields. Other options for name could be 'mem_limit_exceeded_count' or 'mem_limit_hit_count' thanks Shveta
В списке pgsql-hackers по дате отправления: