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 1vV7jF-00DsiL-36 for pgsql-general@arkaria.postgresql.org; Mon, 15 Dec 2025 12:31:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vV7jE-000Hps-13 for pgsql-general@arkaria.postgresql.org; Mon, 15 Dec 2025 12:31:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vV7EA-0008zG-1y for pgsql-general@lists.postgresql.org; Mon, 15 Dec 2025 11:58:59 +0000 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vV7E9-000mVS-02 for pgsql-general@lists.postgresql.org; Mon, 15 Dec 2025 11:58:58 +0000 Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-b7633027cb2so585564966b.1 for ; Mon, 15 Dec 2025 03:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; t=1765799935; x=1766404735; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=QmEEnNW0I9z9pFwpznD/R7Pglf/PIVQrhqVYZtUIduk=; b=EuhFm7F2Fa2X4yJ9fysRlkv6m+ZMiPb8IrYD2qb8TB+PUcbYUWqegcIq5PwZYKYq7N 3/jNVL5OozZr3kCTvKZS4MpUKGaDlTQxTaiKc2GVKw2oV7e75Zd2gDb4inWntBIYQT5C S9QdB1zzGNMyzH8E5bzX/XgAgt2OnXgWc14eU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765799935; x=1766404735; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QmEEnNW0I9z9pFwpznD/R7Pglf/PIVQrhqVYZtUIduk=; b=D1VcH2kJf+b6N3oE36JQ0aXf9gSeQqUzXMSkCD1bjW05flG+1NtI06/sbuxPllHOyo Z/t3FPIKGAE21ZGqmW+iCeg5cOFAaq+WGefzpDEsO94gzwTLLMshuh82x0IOyyrtMAEU r1GM99swD1l3a44uHa+9UL5v/x0vDa3OQvkQMRz13TTVtQp18Y86QoteS2yTM/dWmhSz 1J7EY6AofFK+jz0n/269DTlKRNdyXNtmS+MJkC+J0kW6UA/p7qkFyZYTtD4uBE7Kppwr PABJA+Rxat0cUjvwBxWB9PYZioLi9Lu3TPeHEYYFmWncTuguv7fSmHoUiNormjG1yvep Bozg== X-Gm-Message-State: AOJu0Yw6+55hZVIrbw0wkaSybfkjk7OpXdz2HAzyVS7QR3rIBl0irlCn V7pjGPjqW6QFka3ITDsqlPov9NZ+3HaVLXgJPtO/od9H57eRiDCzE+COmpKHJaOoJdnrsbgxFej JuP+spQH8xl05ttfEBK829jWXAuu3HkIpGJQB0XEK5R1GUUJMYluPJEM= X-Gm-Gg: AY/fxX5bGRIMy8Dls8oF3IWdZhvCsRIIeSPUlHc058PI7xltay4O8UDL/ar0KPKKw/f gt1SgwylXoSLRjULUmRozTEbRhPBlRb+VYhNr29vhqeqo81dTmliJULWR4XobmMfwj56iw29RAQ gXJ8tsJal5h81UH8FhrWZobfTQCneOBfdTiXTLXpanBpsbi6PMhim12UpchhjhpavunpSOQTW2Z XZ9F50wrO71si1WLGvrvUUvZT64qmUDEONqIDVHy6QVMlT1CU9lhYdGry9+4lHnE8VG3qdvbKYJ m+HaSuRZLDro5MWmZrepka5Un4B/ X-Google-Smtp-Source: AGHT+IGALoiAKWtY8trox2GMvPjuGA5PIMObv3LBkPnWXbIktWU7FOhJy9WxSt61vefhg+ssj85RtSYT5iEbIYWB9V8= X-Received: by 2002:a17:907:1ca1:b0:b76:d880:398c with SMTP id a640c23a62f3a-b7d23aaf50cmr1071486466b.61.1765799934499; Mon, 15 Dec 2025 03:58:54 -0800 (PST) MIME-Version: 1.0 From: Ahmed Et-tanany Date: Mon, 15 Dec 2025 12:58:43 +0100 X-Gm-Features: AQt7F2qt9G64h5sY4pvaSLoBlJuLqMOxXRQDisLnSGkvCvwmj9X6TaAXJUVfcV0 Message-ID: Subject: Operational issues when max_replication_slots is exhausted To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000d731d90645fc5528" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d731d90645fc5528 Content-Type: text/plain; charset="UTF-8" Hello PostgreSQL community, We have an issue related to `max_replication_slots` that I am not sure would qualify as a bug, so I thought I would ask here first. Our problem is that when our customers use up all available replication slots 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_replication_slots` requires a restart, we would like to avoid that if possible. One idea we have considered is patching PostgreSQL to add a new GUC parameter that would allow a superuser to reserve a certain number of replication slots usable only for management tasks. 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? Thanks in advance. Best regards, -- Ahmed Et-tanany Aiven: https://aiven.io/ --000000000000d731d90645fc5528 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello PostgreSQL community,

We hav= e an issue related to `max_replication_slots` that I am not sure would qual= ify as a bug,
so I thought I would ask here first.

Our problem is= that when our customers use up all available replication slots for logical= replication,
our database management tasks that also require a slot fai= l (for example, creating the required
replication slot for a new physica= l standby). Since increasing `max_replication_slots` requires
a restart,= we would like to avoid that if possible.

One idea we have considere= d is patching PostgreSQL to add a new GUC parameter that would allow
<= div>a superuser to reserve a certain number of replication slots usable onl= y for management tasks.

Is this a known issue that might be a= ddressed in PostgreSQL at some point? If not,
what would be a good way t= o solve this problem?

Thanks in advance.

Best regards,
<= /div>

--
Ahmed Et-tanany
Aiven: https://aiven.io/<= /a>
--000000000000d731d90645fc5528--