[PATCH] Add max_logical_replication_slots GUC
Hello Hackers,
This patch introduces a new postmaster-level configuration parameter,
max_logical_replication_slots, which limits the number of logical
replication slots that can be created.
Currently, max_replication_slots governs the total number of slots,
but there's no separate limit for logical slots. This patch:
Adds max_logical_replication_slots GUC, defaulting to -1
(falls back to max_replication_slots).
Enforces at server startup that max_logical_replication_slots ≤
max_replication_slots. 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/
Attachments:
0001-Add-max_logical_replication_slots-GUC-v1.patchtext/x-patch; charset=US-ASCII; name=0001-Add-max_logical_replication_slots-GUC-v1.patchDownload+198-4
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)
Right now, all replication slots share a single global limit:
max_replication_slots.
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, *Aiven*
ahmed.ettanany@aiven.io | +491772950423
aiven.io <https://www.aiven.io> | <https://www.facebook.com/aivencloud>
<https://www.linkedin.com/company/aiven/>
<https://twitter.com/aiven_io>
*Aiven Deutschland GmbH*
Alexanderufer 3-7, 10117 Berlin
Geschäftsführer: Oskari Saarenmaa, Kenneth Chen
Amtsgericht Charlottenburg, HRB 209739 B
Import Notes
Reply to msg id not found: 202601281228.eghgn3duoe5b@alvherre.pgsql
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)
Yes, 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/
Import Notes
Reply to msg id not found: 202601281248.qjv5oru7hxlz@alvherre.pgsql
On Wed, Jan 28, 2026 at 10:02 PM Ahmed Et-tanany
<ahmed.ettanany@aiven.io> wrote:
Yes, that's what I meant.
Would something like max_logical_wal_senders also be needed for your purpose?
Otherwise, logical replication connections could exhaust max_wal_senders and
prevent physical replication connections from being established.
That said, adding two separate GUC parameters (i.e.,
max_logical_replication_slots
and max_logical_wal_senders) for this purpose doesn't seem like a
great solution,
though...
Regards,
--
Fujii Masao
On Thu, Jan 29, 2026 at 12:39 PM Fujii Masao <masao.fujii@gmail.com> wrote:
Would something like max_logical_wal_senders also be needed for your
purpose?
Otherwise, logical replication connections could exhaust max_wal_senders
and
prevent physical replication connections from being established.That said, adding two separate GUC parameters (i.e.,
max_logical_replication_slots
and max_logical_wal_senders) for this purpose doesn't seem like a
great solution,
though...
That's a great point! I'm thinking we could potentially avoid
introducing a separate max_logical_wal_senders GUC by reusing
max_logical_replication_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/
On Thu, Jan 29, 2026, at 10:01 AM, Ahmed Et-tanany wrote:
That's a great point! I'm thinking we could potentially avoid
introducing a separate max_logical_wal_senders GUC by reusing
max_logical_replication_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.
You have 2 resources (walsender and replication slot). You are restricting a
resource based on a configuration from another resource. That seems a potential
source of confusion.
--
Euler Taveira
EDB https://www.enterprisedb.com/
On Wed, Jan 28, 2026 at 10:02 PM Ahmed Et-tanany
<ahmed.ettanany@aiven.io> wrote:
Yes, that's what I meant.
FYI there is a related discussion on another thread[1]/messages/by-id/CAEze2WjP0NpAjNioXzLiNkpNQcxCMtaNajaQXfufYVcyFyqW1g@mail.gmail.com; Now that
wal_level='replica' can dynamically become 'logical' WAL level
depending on the logical slot presence, there might be users who want
to allow physical replication while not for logical replication
(decoding) to avoid overheads due to logical WAL logging. Having
separate limits for logical slots and physical slots might help such
use cases too.
Regards,
[1]: /messages/by-id/CAEze2WjP0NpAjNioXzLiNkpNQcxCMtaNajaQXfufYVcyFyqW1g@mail.gmail.com
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
On Thu, Jan 29, 2026 at 6:31 PM Ahmed Et-tanany <ahmed.ettanany@aiven.io> wrote:
On Thu, Jan 29, 2026 at 12:39 PM Fujii Masao <masao.fujii@gmail.com> wrote:
Would something like max_logical_wal_senders also be needed for your purpose?
Otherwise, logical replication connections could exhaust max_wal_senders and
prevent physical replication connections from being established.That said, adding two separate GUC parameters (i.e.,
max_logical_replication_slots
and max_logical_wal_senders) for this purpose doesn't seem like a
great solution,
though...That's a great point! I'm thinking we could potentially avoid
introducing a separate max_logical_wal_senders GUC by reusing
max_logical_replication_slots to decide whether a WAL sender can
start for logical replication.
Won't the walsender automatically exit if the
max_logical_replication_slots is reached? If so, do we really need a
separate GUC to control logical walsenders?
--
With Regards,
Amit Kapila.
On Thu, Jan 29, 2026 at 12:39 PM Fujii Masao <masao.fujii@gmail.com> wrote:
Would something like max_logical_wal_senders also be needed for your
purpose?
Otherwise, logical replication connections could exhaust max_wal_senders
and
prevent physical replication connections from being established.That said, adding two separate GUC parameters (i.e.,
max_logical_replication_slots
and max_logical_wal_senders) for this purpose doesn't seem like a
great solution,
though...
For my purpose, it doesn't actually seem that I would need
max_logical_wal_senders to limit WAL senders. Since each logical connection
always requires a logical replication slot, the actual number of active
logical connections (and logical WAL senders) would ultimately be bounded
by max_logical_replication_slots. My main concern is therefore slot
exhaustion rather than the WAL sender limit.
--
Ahmed Et-tanany
Aiven: https://aiven.io/