On Wed, Jan 28, 2026 at 2:43 PM Euler Taveira <[email protected]> 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/
