Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vl4t9-006gUJ-19 for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Jan 2026 12:43:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vl4t8-001L0y-12 for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Jan 2026 12:43:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vl4t7-001L0n-2z for pgsql-hackers@lists.postgresql.org; Wed, 28 Jan 2026 12:43:14 +0000 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vl4t5-00000000sRX-27Yp for pgsql-hackers@lists.postgresql.org; Wed, 28 Jan 2026 12:43:13 +0000 Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-b8707005183so1036079766b.0 for ; Wed, 28 Jan 2026 04:43:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769604190; cv=none; d=google.com; s=arc-20240605; b=iju0bvGoiAGUVen14EZelBxWFRlIJ3G8ql+vbmJUp4q4EudW1xrCNYtNv9ccAjAHDY PFGXOi+AXwEc3L66cMd99Mg6oaXkfNhqcHZr3HZ/9c0zj476A9l4GGXnRMHbpnqH0oNY MlEkddFOR/ApihIWj39tQjOOv+tlCWgCQhHBGaeo7d+KsSueeb5bTTSEBrSlPddeykmg ROXhHUO91bmJCckETaMfCpJBgZyv636eminUOEktHgwoj6jrju7ITh04RsL18qxPSQtS gTIahpjuWoPOMasVKB+J/dVUCGvrDI4sKvPZRPya3Qo29DlJYebRa3HfD+eRmFD4za4E fD+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=xRrlHXsSoNOOSmgaYA32o5oHkUZuFZ6eAS21c7+Anu0=; fh=kIBt64k7aEk7dZoCaMx0vXGNjeifN/cr1A5pTih48i0=; b=k1OK/heidBcAiQ8NDS8GPAZgzoH0PWGCHDzDOFVbnI5pcamaPTAbpUbXLgRhFZTnvW efnnQZr2EwCj5ZuTbrXoOjDMVCukcoOvccxs+V8+osCKuqoI6+K+oyLp5FOa3wJr4HLr QPBwbw3cvNjwMAc/FtLIXHYVwIUC15abimlj93Nd1KRZ9ZjW9TkP5Fibzd8tzNg9OHCE 5HQ8BIww1cVaQ2vCihnX+IrbWiSdoTxXOZgm9Y7ddGeEQRZNuhRiw1Q9R7xdc622pWeY 7BDnE9hbLdv98RKMA5nCGeputQzCpMGMGMW73Ymi1cVS0HIGSXTLNiLxUvnOEDIrNLoE 5CYQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; t=1769604190; x=1770208990; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xRrlHXsSoNOOSmgaYA32o5oHkUZuFZ6eAS21c7+Anu0=; b=fhwXPD3DT98yBHO5AP6wpOIsRkZRMvP4R62vHjD9G7r7we16Vj8N6PC29VebKeBxfW j80Fb6hxOFNlZlMAqdPuIah11vEFIO9OLE9K/Ec6CKX8W7U5H1G5arN8u6V3ZiYWd5zK xVAWt2t57EYlWDFJpyH8KknDqUVP0ewE3zRWw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769604190; x=1770208990; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xRrlHXsSoNOOSmgaYA32o5oHkUZuFZ6eAS21c7+Anu0=; b=V1BAFGAGUqg8kEX+NZwTeRANcvMqV3oHwX+rxtm6T/WOd41mkKccUK5xvGuBO6eldL U0bhjCKlCpX10Vs6XmvtyflZezYUi8FBd7WbJJDUkhOtd2nciP9u9na5zwUXy/OCK1iW Z5jq7r/djCO1LXqTYcRDOb+2tePitqDXFeUH31DtzF0CjmdVRE+GvzUPDcZYB76YGYLj 4xgeo1TgY7O/qblpu7hSEZK1uzxVzixK7U2af/82tbfF0+a1Tq53yQTq+gmGSr8/PO0b 0R6JkUtw4KRM5oQ25u/yhiftOVrAXGwPR26JiO4ohXnbAXA6U/YG1TS+VRFuppO0Jmry rBMg== X-Gm-Message-State: AOJu0Yxf5cqP6EcjtEHlVBQKeFxSqj/YHG6ESnTGQbjqYZdD8VAIoick kwgh5Cd4OZuNor6UopB58ZSDqjkYNNFby1+icM2lZy5o49FCcRCDRNorbhGrlBTgAs6Zw5VoG6H UQbUWifJPlKS95jjxWftvyxVntmDPCjMwNrsi4LuIrw== X-Gm-Gg: AZuq6aKc7N+9EJBUmsH7nHUKTDorgMgg/y+hPmvID+tCyfnbMwn4y1p7vnAYCcZkQq6 gBkdGqT8e5Mdh/c1sfIgY/cl4fYiNiE1u+rzSlkI5/XnnTMVaDCxr3zI1bx83x0wDieHYPoFNJL eckguYHoOc9dIhyLiWOM+lsQbMiDiW70ZMm15Fq0+59lWnj9nmwdwqlrtM28lXN42zGaCBhIQLz NXBS8XP6p0UHIMaPCkqk16Wzd5eSLabrLSi5k2XG3sUO3sLbYVpdup2G1tk/Va5FWYUq5T9QV/E TgqvGdN8+ITtWYUgknfYjuwbvJxwFkGUyFZbvHs= X-Received: by 2002:a17:907:1c0a:b0:b88:dc6:3967 with SMTP id a640c23a62f3a-b8dab423069mr390486166b.40.1769604189822; Wed, 28 Jan 2026 04:43:09 -0800 (PST) MIME-Version: 1.0 References: <202601281228.eghgn3duoe5b@alvherre.pgsql> In-Reply-To: <202601281228.eghgn3duoe5b@alvherre.pgsql> From: Ahmed Et-tanany Date: Wed, 28 Jan 2026 13:42:58 +0100 X-Gm-Features: AZwV_Qhf4Is7jaBGkvyE2HBZKXIEfkKE1JDoxVx4eLzKY6gtFxF3QVrGgds-b-M Message-ID: Subject: Re: [PATCH] Add max_logical_replication_slots GUC To: =?UTF-8?Q?=C3=81lvaro_Herrera?= Cc: pgsql-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000020c48a06497215b8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000020c48a06497215b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Right now, all replication slots share a single global limit: max_replication_slots. That means logical and physical replication slots compete for the same pool= . In practice, a burst of logical replication activity can exhaust all available replication slots, which in turn prevents physical standbys from connecting or restarting. This is problematic because logical replication slots are often user-manage= d and can grow dynamically, while physical replication slots are infrastructure-critical and expected to remain available. Best regards, -- Ahmed Et-tanany Aiven: https://aiven.io/ On Wed, Jan 28, 2026 at 1:28=E2=80=AFPM =C3=81lvaro Herrera wrote: > Hello, > > On 2026-Jan-28, Ahmed Et-tanany wrote: > > > This provides a separation between logical and total replication > > slots, and allows users to control logical slot usage independently. > > Hmm, why is this useful? > > -- > =C3=81lvaro Herrera 48=C2=B001'N 7=C2=B057'E =E2=80=94 > https://www.EnterpriseDB.com/ > "Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end." (2nd Commandment for C programmers) > --=20 [image: Aiven] *Ahmed Et-tanany* Software Engineer, *Aiven* ahmed.ettanany@aiven.io | +491772950423 aiven.io | *Aiven Deutschland GmbH* Alexanderufer 3-7, 10117 Berlin Gesch=C3=A4ftsf=C3=BChrer: Oskari Saarenmaa, Kenneth Chen Amtsgericht Charlottenburg, HRB 209739 B --00000000000020c48a06497215b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Right now, all replication slots share a single global = limit:
max_replication_slots.

That means logical and physical replication slots compete for the same p= ool.

In practice, a burst of logical replication activity can exhaust all ava= ilable
replication slots, which in turn prevents physical standbys from connecting=
or restarting.

This is problematic because logical replication slots are often user-man= aged
and can grow dynamically, while physical replication slots are
infrastructure-critical and expected to remain available.

Best= regards,

--

Ahmed Et-tanany
Aiven:=C2=A0https://aiven.io/
On Wed, Jan 28, 2026 at 1:28=E2=80=AFPM =C3=81lvaro Herrera &l= t;alvherre@kurilemu.de> wrot= e:
Hello,

On 2026-Jan-28, Ahmed Et-tanany wrote:

> This provides a separation between logical and total replication
> slots, and allows users to control logical slot usage independently.
Hmm, why is this useful?

--
=C3=81lvaro Herrera=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04= 8=C2=B001'N 7=C2=B057'E=C2=A0 =E2=80=94=C2=A0 https://www.Enter= priseDB.com/
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end." (2nd Commandment for C programmers)


--
Ahmed Et-tanany
Software Engineer,=C2=A0Aiven
ahmed.ettanany@aiven.io=C2=A0=C2=A0 |=C2= =A0 =C2=A0+491772950423
aiven.io=C2=A0=C2=A0 | =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
<= /td>
Aiven Deutschland GmbH
Alexa= nderufer 3-7, 10117 Berlin
Gesch=C3=A4ftsf=C3=BChrer: Oskari Saarenmaa, = Kenneth Chen
Amtsgericht Charlottenburg, HRB 209739 B
--00000000000020c48a06497215b8--