Re: [PATCH] Add max_logical_replication_slots GUC - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: [PATCH] Add max_logical_replication_slots GUC
Date
Msg-id 657c2c25-95c8-47a8-8e36-9dc5e892933d@app.fastmail.com
Whole thread Raw
In response to [PATCH] Add max_logical_replication_slots GUC  (Ahmed Et-tanany <ahmed.ettanany@aiven.io>)
Responses Re: [PATCH] Add max_logical_replication_slots GUC
Re: [PATCH] Add max_logical_replication_slots GUC
List pgsql-hackers
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/



pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: RFC: Allow EXPLAIN to Output Page Fault Information
Next
From: Álvaro Herrera
Date:
Subject: Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY