| From: | "Euler Taveira" <euler(at)eulerto(dot)com> |
|---|---|
| To: | "Ahmed Et-tanany" <ahmed(dot)ettanany(at)aiven(dot)io> |
| Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Add max_logical_replication_slots GUC |
| Date: | 2026-01-29 12:55:03 |
| Message-ID: | 8916be9f-a0ab-4fbf-adf6-8fd3ee5239ac@app.fastmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-01-29 13:00:57 | Re: Custom oauth validator options |
| Previous Message | Heikki Linnakangas | 2026-01-29 12:28:28 | Re: Improvements and refactoring in shmem.c |