pgsql-hackers
❮
[PATCH] Add max_logical_replication_slots GUC
- Jump to comment-1Ahmed Et-tanany<ahmed.ettanany@aiven.io>Jan 28, 2026, 11:44 AM UTCHello Hackers,
This patch introduces a new postmaster-level configuration parameter,
maxlogicalreplication_slots, which limits the number of logical
replication slots that can be created.
Currently, maxreplicationslots governs the total number of slots,
but there's no separate limit for logical slots. This patch:
Adds maxlogicalreplication_slots GUC, defaulting to -1
(falls back to maxreplicationslots).
Enforces at server startup that maxlogicalreplication_slots ≤
maxreplicationslots. PostgreSQL will refuse to start if this
is violated or if there are more existing logical slots than
the configured maximum.
Checks the logical slot limit when creating new slots at runtime,
preventing creation beyond the configured maximum.
Updates documentation, sample config, and test_decoding tests
to include logical slot limits.
This provides a separation between logical and total replication
slots, and allows users to control logical slot usage independently.
Best regards,
--
Ahmed Et-tanany
Aiven: https://aiven.io/- Jump to comment-1Álvaro Herrera<alvherre@kurilemu.de>Jan 28, 2026, 12:28 PM UTCHello,
On 2026-Jan-28, Ahmed Et-tanany wrote:This provides a separation between logical and total replication
Hmm, why is this useful?
slots, and allows users to control logical slot usage independently.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end." (2nd Commandment for C programmers)- Jump to comment-1Ahmed Et-tanany<ahmed.ettanany@aiven.io>Jan 28, 2026, 12:43 PM UTCRight now, all replication slots share a single global limit:
maxreplicationslots.
That means logical and physical replication slots compete for the same pool.
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, while physical replication slots are
infrastructure-critical and expected to remain available.
Best regards,
--
Ahmed Et-tanany
Aiven: https://aiven.io/
On Wed, Jan 28, 2026 at 1:28 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:Hello,
On 2026-Jan-28, Ahmed Et-tanany wrote:This provides a separation between logical and total replication
slots, and allows users to control logical slot usage independently.
--
Hmm, why is this useful?
--
Álvaro Herrera 48°01'N 7°57'E —
https://www.EnterpriseDB.com/
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end." (2nd Commandment for C programmers)
[image: Aiven] https://www.aiven.io
Ahmed Et-tanany
Software Engineer, Aivenahmed.ettanany@aiven.io | +491772950423 aiven.io <https://www.aiven.io> | <https://www.facebook.com/aivencloud>
https://twitter.com/aiven_io<https://www.linkedin.com/company/aiven/>
Aiven Deutschland GmbH
Alexanderufer 3-7, 10117 Berlin
Geschäftsführer: Oskari Saarenmaa, Kenneth Chen
Amtsgericht Charlottenburg, HRB 209739 B- Jump to comment-1Álvaro Herrera<alvherre@kurilemu.de>Jan 28, 2026, 12:55 PM UTCOn 2026-Jan-28, Ahmed Et-tanany wrote:
In practice, a burst of logical replication activity can exhaust all
Ah, you mean that users doing CREATE SUBSCRIPTION could cause the limit
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,
to be reached, possibly blocking streaming replication. Yeah, it makes
sense to have a separate limit.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"[PostgreSQL] is a great group; in my opinion it is THE best open source
development communities in existence anywhere." (Lamar Owen)- Jump to comment-1Euler Taveira<euler@eulerto.com>Jan 28, 2026, 1:43 PM UTCOn 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,
Maybe it should be the other way around if you consider that the number of
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.
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 reservedreplicationslots 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
pgusereservedreplicationslots. (Maybe this role name is long but
descriptive.) It defaults to 0.
--
Euler Taveira
EDB https://www.enterprisedb.com/- Jump to comment-1Ahmed Et-tanany<ahmed.ettanany@aiven.io>Jan 29, 2026, 11:33 AM UTCOn 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
I had similar reservations about the naming. I initially started with
physical replication slots is more predictable than the number of logical
replication slots.
minreservedphysicalreplicationslots, but then realized that what
actually makes sense to limit are logical replication slots. That's
why I switched to maxlogicalreplication_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 andlogical but have a reservedreplicationslots parameter. The concept is
I find the idea of a reservedreplicationslots parameter
similar
to reserved_connections. It defines the number of (physical or logical)
replication slots that are reserved by roles with privileges of the
pgusereservedreplicationslots. (Maybe this role name is long but
descriptive.) It defaults to 0.
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/- Jump to comment-1Euler Taveira<euler@eulerto.com>Jan 29, 2026, 12:55 PM UTCOn Thu, Jan 29, 2026, at 8:33 AM, Ahmed Et-tanany wrote:
If the role credentials are valid and the role has REPLICATION privilege, it
I find the idea of a reservedreplicationslots 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.
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
As Fujii said I'm afraid we also need another GUC (for WAL senders) since X
the number of logical slots, or explore the role-based reservation
idea more in-depth.
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/
- Jump to comment-1Bernd Helmle<mailings@oopsware.de>Jan 29, 2026, 10:06 AM UTCAm Mittwoch, dem 28.01.2026 um 10:43 -0300 schrieb Euler Taveira:
Another idea is to not differentiate between physical and
I like your second idea. That makes it independent from what you like
logical but have a reservedreplicationslots 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
pgusereservedreplicationslots. (Maybe this role name is long but
descriptive.) It defaults to 0.
to reserve for, either logical or physical and supports flexible pool
configurations.
--
Thanks,Bernd
- Jump to comment-1Ahmed Et-tanany<ahmed.ettanany@aiven.io>Jan 28, 2026, 1:02 PM UTCYes, that's what I meant.
On Wed, Jan 28, 2026 at 1:55 PM Álvaro Herrera <alvherre@kurilemu.de> 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.
--
Álvaro Herrera PostgreSQL Developer —
https://www.EnterpriseDB.com/
"[PostgreSQL] is a great group; in my opinion it is THE best open source
development communities in existence anywhere." (Lamar Owen)
Ahmed Et-tanany
Aiven: https://aiven.io/- Jump to comment-1Fujii Masao<masao.fujii@gmail.com>Jan 29, 2026, 11:40 AM UTCOn Wed, Jan 28, 2026 at 10:02 PM Ahmed Et-tanany
<ahmed.ettanany@aiven.io> wrote:
Would something like maxlogicalwal_senders also be needed for your purpose?
Yes, that's what I meant.
Otherwise, logical replication connections could exhaust maxwalsenders and
prevent physical replication connections from being established.
That said, adding two separate GUC parameters (i.e.,
maxlogicalreplication_slots
and maxlogicalwal_senders) for this purpose doesn't seem like a
great solution,
though...
Regards,
--
Fujii Masao- Jump to comment-1Ahmed Et-tanany<ahmed.ettanany@aiven.io>Jan 29, 2026, 1:01 PM UTCOn Thu, Jan 29, 2026 at 12:39 PM Fujii Masao <masao.fujii@gmail.com> wrote:
That's a great point! I'm thinking we could potentially avoid
Would something like maxlogicalwal_senders also be needed for your
purpose?
Otherwise, logical replication connections could exhaust maxwalsenders
and
prevent physical replication connections from being established.
That said, adding two separate GUC parameters (i.e.,
maxlogicalreplication_slots
and maxlogicalwal_senders) for this purpose doesn't seem like a
great solution,
though...
introducing a separate maxlogicalwal_senders GUC by reusing
maxlogicalreplication_slots to decide whether a WAL sender can
start for logical replication.
This way, the limit on logical slots would also indirectly cap
the number of logical WAL senders, helping protect physical
replication connections without adding another configuration
parameter.
What do you think about this approach?
Best regards,
--
Ahmed Et-tanany
Aiven: https://aiven.io/- Jump to comment-1Euler Taveira<euler@eulerto.com>Jan 29, 2026, 1:22 PM UTCOn Thu, Jan 29, 2026, at 10:01 AM, Ahmed Et-tanany wrote:
You have 2 resources (walsender and replication slot). You are restricting a
That's a great point! I'm thinking we could potentially avoid
introducing a separate maxlogicalwal_senders GUC by reusing
maxlogicalreplication_slots to decide whether a WAL sender can
start for logical replication.
This way, the limit on logical slots would also indirectly cap
the number of logical WAL senders, helping protect physical
replication connections without adding another configuration
parameter.
resource based on a configuration from another resource. That seems a potential
source of confusion.
--
Euler Taveira
EDB https://www.enterprisedb.com/