MIME-Version: 1.0
References: 
 <CAD7nQBD1iy3NAS2YRDUH+zk0g=50px_h_wRsLcFkai7R_RF6VQ@mail.gmail.com>
 <202601281248.qjv5oru7hxlz@alvherre.pgsql>
 <CAD7nQBCfgCeTwO=45OXhGc=wpYBrWXJfzJKRy+T26_jALxatLg@mail.gmail.com>
 <CAHGQGwEaBw9dd+Nzb2ETDJ-40nJTo6GRXrG_FcP0rmw3_-qU_Q@mail.gmail.com>
In-Reply-To: 
 <CAHGQGwEaBw9dd+Nzb2ETDJ-40nJTo6GRXrG_FcP0rmw3_-qU_Q@mail.gmail.com>
From: Ahmed Et-tanany <ahmed.ettanany@aiven.io>
Date: Mon, 9 Mar 2026 17:09:13 +0100
Message-ID: 
 <CAD7nQBBuhmUo5L4SU=QGmknpN-JJ4mS8OZDM+Rt0qC_1t1ev3g@mail.gmail.com>
Subject: Re: [PATCH] Add max_logical_replication_slots GUC
To: Fujii Masao <masao.fujii@gmail.com>
Cc: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>,
	pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="00000000000058e1d4064c99a0fb"
Archived-At: 
 <https://www.postgresql.org/message-id/CAD7nQBBuhmUo5L4SU%3DQGmknpN-JJ4mS8OZDM%2BRt0qC_1t1ev3g%40mail.gmail.com>
Precedence: bulk

--00000000000058e1d4064c99a0fb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 29, 2026 at 12:39=E2=80=AFPM Fujii Masao <masao.fujii@gmail.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.

--=20
Ahmed Et-tanany
Aiven: https://aiven.io/

--00000000000058e1d4064c99a0fb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jan 29, 2026 at 12:39=E2=80=AFPM =
Fujii Masao &lt;<a href=3D"mailto:masao.fujii@gmail.com">masao.fujii@gmail.=
com</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
Would something like max_logical_wal_senders also be needed for your purpos=
e?<br>
Otherwise, logical replication connections could exhaust max_wal_senders an=
d<br>
prevent physical replication connections from being established.<br>
<br>
That said, adding two separate GUC parameters (i.e.,<br>
max_logical_replication_slots<br>
and max_logical_wal_senders) for this purpose doesn&#39;t seem like a<br>
great solution,<br>
though...<br></blockquote><div><br></div><div>For my purpose, it doesn&#39;=
t actually seem that I would need <code>max_logical_wal_senders</code> to l=
imit WAL senders. Since each logical connection always requires a logical r=
eplication slot, the actual number of active logical connections (and logic=
al WAL senders) would ultimately be bounded by <code>max_logical_replicatio=
n_slots</code>. My main concern is therefore slot exhaustion rather than th=
e WAL sender limit.</div></div><div><br></div><span class=3D"gmail_signatur=
e_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=
=3D"ltr"><span style=3D"color:rgb(0,0,0);font-family:monospace,monospace;fo=
nt-size:10.7333px">Ahmed Et-tanany</span><br style=3D"color:rgb(0,0,0);font=
-family:monospace,monospace;font-size:10.7333px"><span style=3D"color:rgb(0=
,0,0);font-family:monospace,monospace;font-size:10.7333px">Aiven: </span><a=
 href=3D"https://aiven.io/" rel=3D"nofollow" style=3D"color:rgb(132,0,50);b=
ackground-color:transparent;font-weight:600;font-family:monospace,monospace=
;font-size:10.7333px" target=3D"_blank">https://aiven.io/</a></div></div></=
div>

--00000000000058e1d4064c99a0fb--