Re: [PATCH] Add max_logical_replication_slots GUC
On Wed, Jan 28, 2026, at 9:54 AM, Álvaro Herrera wrote:
On 2026-Jan-28, Ahmed Et-tanany wrote:
In practice, a burst of logical replication activity can exhaust all
available replication slots, which in turn prevents physical standbys
from connecting or restarting.This is problematic because logical replication slots are often
user-managed and can grow dynamically,Ah, you mean that users doing CREATE SUBSCRIPTION could cause the limit
to be reached, possibly blocking streaming replication. Yeah, it makes
sense to have a separate limit.
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. 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.
--
Euler Taveira
EDB https://www.enterprisedb.com/
Import Notes
Reply to msg id not found: 202601281248.qjv5oru7hxlz@alvherre.pgsqlReference msg id not found: 202601281248.qjv5oru7hxlz@alvherre.pgsql
Am Mittwoch, dem 28.01.2026 um 10:43 -0300 schrieb Euler Taveira:
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 like your second idea. That makes it independent from what you like
to reserve for, either logical or physical and supports flexible pool
configurations.
--
Thanks,
Bernd
On Wed, Jan 28, 2026 at 2:43 PM Euler Taveira <euler@eulerto.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/
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.
--
Euler Taveira
EDB https://www.enterprisedb.com/
On Thu, Jan 29, 2026 at 1:55 PM Euler Taveira <euler@eulerto.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/