Re: [PATCH] Add max_logical_replication_slots GUC

On Thu, Jan 29, 2026 at 1:55 PM Euler Taveira <euler(at)eulerto(dot)com> wrote:

> On Thu, Jan 29, 2026, at 8:33 AM, Ahmed Et-tanany wrote:
> >
> > 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.
> >
>
> If the role credentials are valid and the role has REPLICATION privilege,
> it
> can use any replication slots. The proposal is an extra requirement to
> allow
> the role to use a reserved pool of replication slots. I don't think the
> resource (replication slot) needs ownership and privileges for a
> fine-grained
> control.
>
> > 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.
> >
>
> As Fujii said I'm afraid we also need another GUC (for WAL senders) since X
> active replication slots implies at least X walsenders. In order to
> guarantee
> there won't be physical replication interruption, you also need to
> guarantee
> that there will be a walsender available.
>

I started exploring the reserved_replication_slots idea, and unless
I'm missing something, the WAL senders issue raised by Fujii still
applies there as well. We would therefore still need an additional
mechanism (e.g., another GUC such as reserved_wal_senders) to ensure
that WAL senders are not entirely consumed by logical replication.

Given that, I'm wondering what would be the preferred way to avoid
introducing two separate GUCs under either approach.

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