Re: [PATCH] Add max_logical_replication_slots GUC

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/

In response to

Browse pgsql-hackers by date

  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