Horton

Thread

  1. [PATCH] Add max_logical_replication_slots GUC

    Ahmed Et-tanany <ahmed.ettanany@aiven.io> — 2026-01-28T10:16:21Z

    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/

  2. Re: [PATCH] Add max_logical_replication_slots GUC

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-01-28T12:28:38Z

    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)

  3. Re: [PATCH] Add max_logical_replication_slots GUC

    Ahmed Et-tanany <ahmed.ettanany@aiven.io> — 2026-01-28T12:42:58Z

    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

  4. Re: [PATCH] Add max_logical_replication_slots GUC

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-01-28T12:54:32Z

    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)

  5. Re: [PATCH] Add max_logical_replication_slots GUC

    Ahmed Et-tanany <ahmed.ettanany@aiven.io> — 2026-01-28T13:02:01Z

    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/

  6. Re: [PATCH] Add max_logical_replication_slots GUC

    Euler Taveira <euler@eulerto.com> — 2026-01-28T13:43:25Z

    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/

  7. Re: [PATCH] Add max_logical_replication_slots GUC

    Bernd Helmle <mailings@oopsware.de> — 2026-01-29T10:05:53Z

    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

  8. Re: [PATCH] Add max_logical_replication_slots GUC

    Ahmed Et-tanany <ahmed.ettanany@aiven.io> — 2026-01-29T11:33:28Z

    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/

  9. Re: [PATCH] Add max_logical_replication_slots GUC

    Fujii Masao <masao.fujii@gmail.com> — 2026-01-29T11:39:42Z

    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

  10. Re: [PATCH] Add max_logical_replication_slots GUC

    Euler Taveira <euler@eulerto.com> — 2026-01-29T12:55:03Z

    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/

  11. Re: [PATCH] Add max_logical_replication_slots GUC

    Ahmed Et-tanany <ahmed.ettanany@aiven.io> — 2026-01-29T13:01:22Z

    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/

  12. Re: [PATCH] Add max_logical_replication_slots GUC

    Euler Taveira <euler@eulerto.com> — 2026-01-29T13:21:48Z

    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/

  13. Re: [PATCH] Add max_logical_replication_slots GUC

    Ahmed Et-tanany <ahmed.ettanany@aiven.io> — 2026-02-02T11:18:29Z

    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/

  14. Re: [PATCH] Add max_logical_replication_slots GUC

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-02-04T00:54:57Z

    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]; 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

  15. Re: [PATCH] Add max_logical_replication_slots GUC

    Amit Kapila <amit.kapila16@gmail.com> — 2026-02-11T12:09:37Z

    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.

  16. Re: [PATCH] Add max_logical_replication_slots GUC

    Ahmed Et-tanany <ahmed.ettanany@aiven.io> — 2026-03-09T16:09:13Z

    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/

  17. Re: [PATCH] Add max_logical_replication_slots GUC

    shveta malik <shveta.malik@gmail.com> — 2026-03-10T06:54:59Z

    On Thu, Jan 29, 2026 at 5:10 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> 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.
>

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

  18. Re: [PATCH] Add max_logical_replication_slots GUC

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-03-24T00:13:57Z

    Hi,

On Mon, Mar 9, 2026 at 11:55 PM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Thu, Jan 29, 2026 at 5:10 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> >
> > 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.
> >
>
> 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?

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,

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