Re: [PATCH] Add max_logical_replication_slots GUC

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>, "Ahmed Et-tanany" <ahmed(dot)ettanany(at)aiven(dot)io>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Add max_logical_replication_slots GUC
Date: 2026-01-28 13:43:25
Message-ID: 657c2c25-95c8-47a8-8e36-9dc5e892933d@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2026-01-28 14:33:21 Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
Previous Message torikoshia 2026-01-28 13:27:04 Re: RFC: Allow EXPLAIN to Output Page Fault Information