Re: [PATCH] Add max_logical_replication_slots GUC

On Wed, Jan 28, 2026 at 2:43 PM Euler Taveira <euler(at)eulerto(dot)com> wrote:

> Maybe it should be the other way around if you consider that the number of
> physical replication slots is more predictable than the number of logical
> replication slots.

I had similar reservations about the naming. I initially started with
min_reserved_physical_replication_slots, but then realized that what
actually makes sense to limit are logical replication slots. That's
why I switched to max_logical_replication_slots. But sure, if we go
down this path, we can revisit the naming to ensure it aligns with
what makes the most sense.

Another idea is to not differentiate between physical and
> logical but have a reserved_replication_slots parameter. The concept is
> similar
> to reserved_connections. It defines the number of (physical or logical)
> replication slots that are reserved by roles with privileges of the
> pg_use_reserved_replication_slots. (Maybe this role name is long but
> descriptive.) It defaults to 0.
>

I find the idea of a reserved_replication_slots parameter
interesting. However, I'm thinking about the amount of additional
semantics we'd need to introduce to properly manage slot ownership,
since we currently don't have the concept of a role specifically
reserving or owning a replication slot.

It seems to me we'd either keep it simple and focus on just limiting
the number of logical slots, or explore the role-based reservation
idea more in-depth.

Looking forward to hearing more thoughts on this!

Best regards,

--
Ahmed Et-tanany
Aiven: https://aiven.io/