Subject: Re: [PATCH] Add max_logical_replication_slots GUC

From: Ahmed Et-tanany <[email-masked]>
Date: Wed, 28 Jan 2026 13:42:58 +0100

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 <[email-masked]> 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)
>

-- 
 <https://www.aiven.io>
*Ahmed Et-tanany*
Software Engineer, *Aiven*
[email-masked]   |   +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

---

From: Álvaro Herrera <[email-masked]>
Date: Wed, 28 Jan 2026 13:54:32 +0100

On 2026-Jan-28, Ahmed Et-tanany wrote:

> 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)

---

From: Ahmed Et-tanany <[email-masked]>
Date: Wed, 28 Jan 2026 14:02:01 +0100

Yes, that's what I meant.

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

---

From: Fujii Masao <[email-masked]>
Date: Thu, 29 Jan 2026 20:39:42 +0900

> 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

---

From: Ahmed Et-tanany <[email-masked]>
Date: Thu, 29 Jan 2026 14:01:22 +0100

> and max_logical_wal_senders) for this purpose doesn't seem like a
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/

---

From: Masahiko Sawada <[email-masked]>
Date: Wed, 4 Feb 2026 09:54:57 +0900

> Yes, that's what I meant.

FYI there is a related discussion on another thread[1]; 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] https://www.postgresql.org/message-id/CAEze2WjP0NpAjNioXzLiNkpNQcxCMtaNajaQXfufYVcyFyqW1g%40mail.gmail.com

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

---

From: Amit Kapila <[email-masked]>
Date: Wed, 11 Feb 2026 17:39:37 +0530

> 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.

---

From: Ahmed Et-tanany <[email-masked]>
Date: Mon, 9 Mar 2026 17:09:13 +0100

> and max_logical_wal_senders) for this purpose doesn't seem like a

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/

---

From: shveta malik <[email-masked]>
Date: Tue, 10 Mar 2026 12:24:59 +0530

> prevent physical replication connections from being established.

I could be mistaken, but I haven’t found a way to start a logical
replication stream without a replication slot. A replication
connection and walsender can exist without a slot, for example:
./psql "host=localhost port=5432 user=user1 dbname=postgres
replication=database"

However, converting that connection to logical replication requires a
slot from the max_logical_replication_slots pool. If that pool is
exhausted, the connection cannot be converted — in which case,
wouldn’t a single GUC suffice?

I might be missing something — are you referring to a different scenario?
One possibility is if max_wal_senders is lower than
max_logical_replication_slots, which could exhaust WAL senders for
logical connections, though that would mostly be a configuration
issue. Isn't it?

thanks
Shveta

---

From: Masahiko Sawada <[email-masked]>
Date: Mon, 23 Mar 2026 17:13:57 -0700

Hi,

> wouldn’t a single GUC suffice?

In an extreme case like where if all walsenders are used up by logical
walsender who are just connecting and not using logical replication
slots, physical replication cannot start even if there is a free
physical replication slot. But I think it's sufficient to have
something like max_logical_replication_slots in most cases. So a
single GUC seems to suffice unless I'm not missing some cases.

Regards,