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 1vT6Gq-00Cp65-0A for pgsql-general@arkaria.postgresql.org; Tue, 09 Dec 2025 22:33:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vT6Go-007k1T-03 for pgsql-general@arkaria.postgresql.org; Tue, 09 Dec 2025 22:33:22 +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 1vT6Gn-007k1L-1w for pgsql-general@lists.postgresql.org; Tue, 09 Dec 2025 22:33:21 +0000 Received: from sm-r-008-dus.org-dns.com ([84.19.1.236]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vT6Gk-0040ZJ-3A for pgsql-general@lists.postgresql.org; Tue, 09 Dec 2025 22:33:21 +0000 Received: from smarthost-dus.org-dns.com (localhost [127.0.0.1]) by smarthost-dus.org-dns.com (Postfix) with ESMTP id D915EA1A5B for ; Tue, 9 Dec 2025 23:33:15 +0100 (CET) Received: by smarthost-dus.org-dns.com (Postfix, from userid 1001) id CBECAA1A6A; Tue, 9 Dec 2025 23:33:15 +0100 (CET) X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,DMARC_PASS,KAM_INFOUSMEBIZ,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 Received: from ha01s018.org-dns.com (ha01s018.org-dns.com [62.108.32.138]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smarthost-dus.org-dns.com (Postfix) with ESMTPS id 84564A1A5B for ; Tue, 9 Dec 2025 23:33:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gelassene-pferde.biz; s=default; t=1765319594; bh=Hiiaa441Lc0ga+jK4aqhQgI1vvOQZYWRnJcO5HS26Tg=; h=Subject:To:From; b=s3uzNrwkRcPq666kFWv5nzH5Fr5LhIagPT2z5Nawqj4lNgIboE8NJhEP7n67zfLfD JWj1PWrzB1ZN6ZvluDp5RGOqD/QH3r0UnQysMv5WnLNzXrKkf3pfORzj8cP8/y8+Ej b2QxJhooWahPekKwyzhapRpta2UN2i+f42Bmcr5k= Authentication-Results: ha01s018.org-dns.com; spf=pass (sender IP is 146.185.68.202) smtp.mailfrom=thiemo@gelassene-pferde.biz smtp.helo=[192.168.178.23] Received-SPF: pass (ha01s018.org-dns.com: connection is authenticated) Message-ID: Date: Tue, 9 Dec 2025 23:33:13 +0100 MIME-Version: 1.0 Subject: Re: How do I check for NULL To: pgsql-general References: Content-Language: en-GB From: Thiemo Kellner In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <176531959439.418080.16427051332155840866@ha01s018.org-dns.com> X-PPP-Vhost: gelassene-pferde.biz X-POWERED-BY: wint.global - AV:CLEAN SPAM:OK List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 12/9/25 18:29, David G. Johnston wrote: > On Tue, Dec 9, 2025 at 10:14 AM Thiemo Kellner > wrote: > > I feel, you meant to say, the subquery does not return any record > which is not the same as returns NULL. > > > For a scalar subquery the final output of a zero-row query is the null > value. > To me, it does not look like that (please note the empty line in the last example). Can you point me to the documentation saying that 0 rows is sometimes equal to 1 row? postgres=# select * from pg_user;  usename  | usesysid | usecreatedb | usesuper | userepl | usebypassrls |  passwd  | valuntil | useconfig ----------+----------+-------------+----------+---------+--------------+----------+----------+-----------  postgres |       10 | t           | t        | t       | t   | ******** |          | (1 row) postgres=# select usename from pg_user where false;  usename --------- (0 rows) postgres=# select null as usename from pg_user;  usename --------- (1 row) 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 1vVAKl-00EYBp-0N for pgsql-general@arkaria.postgresql.org; Mon, 15 Dec 2025 15:18:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vVAKj-000vEw-2Q for pgsql-general@arkaria.postgresql.org; Mon, 15 Dec 2025 15:17:58 +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 1vVAKj-000vEm-1F for pgsql-general@lists.postgresql.org; Mon, 15 Dec 2025 15:17:58 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vVAKi-000nyt-04 for pgsql-general@lists.postgresql.org; Mon, 15 Dec 2025 15:17:57 +0000 Received: by mail-wm1-x344.google.com with SMTP id 5b1f17b1804b1-4779a637712so24236895e9.1 for ; Mon, 15 Dec 2025 07:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec.at; s=google; t=1765811874; x=1766416674; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=qzsn87/VBzTo1GifiqzVJUtxRGyzbM0AYrJc0ecOCoQ=; b=NGXBmZPvF9tkJjD2XGPYqzy5RMq4QLNNTlPD4QB3F3dRdE2cjZ/xVCl0C3h8mO7lyt YJV6cE41MCTLNqTZ+0y1PBLn8uCf1YyU+4e+bht88L7QR0wpDPYztZHaiw5YsDqjWWLP 4Sa4tFx6Jt8wedlkUxM+1Rv4W6fQszuv+BHeJ0dQZRXaFdUPQliMjWX89NWvK7KZH/iI kdWTm16B2Dg2AEMr5FL2Jr2lG7cCpPmxv/D6S4osy3d8mYbq47akYpaFOh8Qk+6oaOZ/ ZTgRpwIaHjrhlrLkkJk4w8x2GQ/xV77wyzHU6C1uYHmTa3mv3pUC49Atci8h+HOKd4om PkVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765811874; x=1766416674; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qzsn87/VBzTo1GifiqzVJUtxRGyzbM0AYrJc0ecOCoQ=; b=Bnk2o7rkFUKssWh1fMuJSaHgTQKsi62sRwmmScVZ2ocdoLjeOa9Y2oWemsAPxCicli cO3J2CvL/JyHwKHwc5prSK+cZTIBnmbdfTJuiF11w0PCqIdlC4tq/q2nQrMZ/WhuF6Ky zY8p1JmdNy4u5cWyWeTKSXDYzHPBWnxCIlanPMN/pkrdG0jgt/jrSTZHhIMc9esarh7m CDoHxzJ92VML6p5eiKqn2+peOyyJ2Eyow9iqmdagKTx7eB2Hnk7ekrHZZWHGp3TjVTq6 OL2zXXsfeUOUS62e01Hc/CJCoOkrNpCkOCd5XUSvzEsmxOR5C5OxCjlsRFv2qFhiTkEm 1UOQ== X-Forwarded-Encrypted: i=1; AJvYcCWZ8ksKldOvsycF3cc3QmaImRZBYQtQC3pkpPs0akv6ET4drEPuhIdLXAbn+TxYXDcmaLOrrFbNNlpVZd0B@lists.postgresql.org X-Gm-Message-State: AOJu0Ywu4G2h4TYaVTjcjmOw30r2+Trcx9ydpogTxrKaKbxQyOYI7XNB nhmxbA3SpIJvk0aZROBs135l7H+P7BbDthyrDpdwzCH26ufAiUkqn7BJJzHVp7Ph4AQk82+NXyg ZyQggg3CsD92V X-Gm-Gg: AY/fxX5rGsIERUkyDYPzszfA6DtG/wkM0MOusifJC82K2qFcGozyA2lTnOML29KaDAa g86oe54kUq+jhMuiFJmEpo4DUJcWX56d54JpCsZ88cNUxxkjTo/sn+yN5iiPCLkCkyKpL4ap1rN 3GHf7Bsrk3g4+xaEKxdP9s9781MU4J1yCZnsY4ZTDSM9gGQcZyjmSnWeW53r16PAh0hqtQ++4UC NImnEPbim9sVJnV4P0qTSrT20jvHi5sKWW/JfM8EOVoOMR6d8yZ5NF8kj5+IcEb3UEkfkATmJn4 4Bqb71c8hr3rPdG2ZSxkjijRTvqzdjb6/Y/5d2EVdQks9E4l/9JZNS1ea5Ky4q4qoK8L0vdtJSN incbQ1G1ZpN6cRlA+FpdlDJNrMkTVJVDH8IT6D/hyQsFYT4eYQcbD1KGMBo2TzVguSdxpqe7UgW hnwdSnyC4wbgqM9mscWTeEthXEWTNbV4zFOX4nrXee0g== X-Google-Smtp-Source: AGHT+IFKvTUvIv/AFrqQwYh2yFpbvwp3Gqz0o/YHjEzg1NaRXrig8fJCKfYZ6hWTF6GqyV4840ux5w== X-Received: by 2002:a05:600c:4e47:b0:477:3e0b:c0e3 with SMTP id 5b1f17b1804b1-47a8f9155c6mr92066245e9.32.1765811873569; Mon, 15 Dec 2025 07:17:53 -0800 (PST) Received: from laurenz.albe-K4N0CV00F97414D ([2001:871:70:4d5d:eedd:3dd9:428c:9522]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47a8f49da20sm190280675e9.5.2025.12.15.07.17.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Dec 2025 07:17:53 -0800 (PST) Message-ID: Subject: Re: Operational issues when max_replication_slots is exhausted From: Laurenz Albe To: Ahmed Et-tanany , pgsql-general@lists.postgresql.org Date: Mon, 15 Dec 2025 16:17:52 +0100 In-Reply-To: References: 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 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-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