| 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-03-09 16:09:13 |
| Message-ID: | CAD7nQBBuhmUo5L4SU=QGmknpN-JJ4mS8OZDM+Rt0qC_1t1ev3g@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...
>
For my purpose, it doesn't actually seem that I would need
max_logical_wal_senders to limit WAL senders. Since each logical connection
always requires a logical replication slot, the actual number of active
logical connections (and logical WAL senders) would ultimately be bounded
by max_logical_replication_slots. My main concern is therefore slot
exhaustion rather than the WAL sender limit.
--
Ahmed Et-tanany
Aiven: https://aiven.io/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ranier Vilela | 2026-03-09 16:25:20 | Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c) |
| Previous Message | Nathan Bossart | 2026-03-09 15:51:01 | Re: Add starelid, attnum to pg_stats and leverage this in pg_dump |