Message-ID: <bfd667fac146fd2ff451b6c0b0750d7f979cf6b0.camel@cybertec.at>
Subject: Re: Operational issues when max_replication_slots is exhausted
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Ahmed Et-tanany <ahmed.ettanany@aiven.io>, 
	pgsql-general@lists.postgresql.org
Date: Mon, 15 Dec 2025 16:17:52 +0100
In-Reply-To: <CAD7nQBASDnsxiThkH3=SZLb-=uBT7GJvZBxqY9PYUNHJdSeESA@mail.gmail.com>
References: 
	<CAD7nQBASDnsxiThkH3=SZLb-=uBT7GJvZBxqY9PYUNHJdSeESA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/bfd667fac146fd2ff451b6c0b0750d7f979cf6b0.camel%40cybertec.at>
Precedence: bulk

On Mon, 2025-12-15 at 12:58 +0100, Ahmed Et-tanany wrote:
> Our problem is that when our customers use up all available replication s=
lots for logical replication,
> our database management tasks that also require a slot fail (for example,=
 creating the required
> replication slot for a new physical standby). Since increasing `max_repli=
cation_slots` requires
> a restart, we would like to avoid that if possible.
>=20
> One idea we have considered is patching PostgreSQL to add a new GUC param=
eter that would allow
> a superuser to reserve a certain number of replication slots usable only =
for management tasks.
>=20
> Is this a known issue that might be addressed in PostgreSQL at some point=
? If not,
> what would be a good way to solve this problem?

It is conceivable that somebody might change the behavior at some point (co=
mpare
"reserved_connections").  If you write or sponsor a patch, that would incre=
ase
the likelihood.

Right now, my only suggestion is to set "max_replication_slots" high.

Yours,
Laurenz Albe