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