| From: | Ahmed Et-tanany <ahmed(dot)ettanany(at)aiven(dot)io> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| 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 13:01:22 |
| Message-ID: | CAD7nQBCwWj=v0QE6HL3BDOPrbqE1raniZ6DRPi_cyLxv81+HJQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 29, 2026 at 12:39 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Euler Taveira | 2026-01-29 13:21:48 | Re: [PATCH] Add max_logical_replication_slots GUC |
| Previous Message | Zsolt Parragi | 2026-01-29 13:00:57 | Re: Custom oauth validator options |