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 1vUjbz-006heb-2h for pgsql-admin@arkaria.postgresql.org; Sun, 14 Dec 2025 10:46:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vUjby-00CaFE-2Y for pgsql-admin@arkaria.postgresql.org; Sun, 14 Dec 2025 10:45:59 +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 1vUUFT-00BNRm-2G for pgsql-admin@lists.postgresql.org; Sat, 13 Dec 2025 18:21:44 +0000 Received: from cc-smtpout1.netcologne.de ([2001:4dd0:100:1062:25:2:0:1]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vUUFS-000VZ9-0J for pgsql-admin@lists.postgresql.org; Sat, 13 Dec 2025 18:21:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1765650093; bh=rjehpagfA1Ry/lIlfjghTiVw6goOyj1MnBJmpSgHG3I=; h=Message-ID:Date:Subject:To:References:From:In-Reply-To:From; b=R3KfaPzA7a/Fp/gPuZ/K2CFCFEscsL8hM1N5ZmylijeDbFfVtdQeghOKXvCcKnvj0 9tQsH2+ubM7nsWRerOtFTe7WVkNK7pO4UOrZ0Nn5gnHFcN91Bq4+tZiQze2g2qViaD +z2NOrlmeb7hHSAAG1JID/twPy+s/jd2CI8Ip2a5lzsyxsp77dhDzFjRsOvVu9Im4h r1LF7b0NYDMgtUq4CwdOMVXNq1fLcsRvBSG6L57OZEvueccXHj/L6QcjTTBh1qZwAc doQz4wV1O84l0hJeS3I8GFDOhPAKDHzc6cx3It2O0x6GeL5wVuSEYl9iwEbTmyytbq 5qWIXJMZFCYyw== Received: from cc-smtpin3.netcologne.de (cc-smtpin3.netcologne.de [89.1.8.203]) by cc-smtpout1.netcologne.de (Postfix) with ESMTP id 71DA711DA5 for ; Sat, 13 Dec 2025 19:21:33 +0100 (CET) Received: from [IPV6:2a03:b580:aff7:d901:d2:923d:27d5:50d1] (unknown [IPv6:2a03:b580:aff7:d901:d2:923d:27d5:50d1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin3.netcologne.de (Postfix) with ESMTPSA id 410A411D88 for ; Sat, 13 Dec 2025 19:21:33 +0100 (CET) Content-Type: multipart/alternative; boundary="------------sZ8N5hWzHar85Pgyz5RwLvNQ" Message-ID: <6678e492-b544-4ad3-bd79-2dd3ff3cefaa@netcologne.de> Date: Sat, 13 Dec 2025 19:22:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: pgping? To: pgsql-admin@lists.postgresql.org References: <2046739.1758254802@sss.pgh.pa.us> <471a0d22-f769-450d-a084-74ece10915d5@netcologne.de> Content-Language: en-US From: Gunnar In-Reply-To: X-NetCologne-Spam: L List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------sZ8N5hWzHar85Pgyz5RwLvNQ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/13/25 15:54, David G. Johnston wrote: > > > On Friday, December 12, 2025, Gunnar wrote: > > > my latest experience with pg_isready reminded me that it only > works on a general level (cluster ready generally) though. > If you include a database to the command it still reports true > even if the database you want to address does not exist. > > That said I remember that I read this was broken since ... > forever, which means nobody cares. > > > It isn’t broken - it is working precisely as intended and required for > the use cases it’s meant to solve.  That’s why no one is fixing it.  > These people that want it to solve additional use cases need to step > up and implement some new features for it. hm, one might argue, that if the use case 'pg_isready -d database' is mentioned in the manual this could be seen as the aspiration, or maybe even commitment to that feature. Even the description of pg_isready --help mentions a "connection check to a database", not a cluster. Do I misinterpret the manual/help? If that was the case my next question was ... what is the purpose of the option -d, --dbname=DBNAME ? all best ... Gunnar --------------sZ8N5hWzHar85Pgyz5RwLvNQ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 12/13/25 15:54, David G. Johnston wrote:


On Friday, December 12, 2025, Gunnar <tongji@netcologne.de> wrote:

my latest experience with pg_isready reminded me that it only works on a general level (cluster ready generally) though.
If you include a database to the command it still reports true even if the database you want to address does not exist.

That said I remember that I read this was broken since ... forever, which means nobody cares.


It isn’t broken - it is working precisely as intended and required for the use cases it’s meant to solve.  That’s why no one is fixing it.  These people that want it to solve additional use cases need to step up and implement some new features for it.

hm, one might argue, that if the use case 'pg_isready -d database' is mentioned in the manual this could be seen as the aspiration, or maybe even commitment to that feature.
Even the description of pg_isready --help mentions a "connection check to a database", not a cluster.

Do I misinterpret the manual/help? If that was the case my next question was ... what is the purpose of the option -d, --dbname=DBNAME ?

all best ... Gunnar --------------sZ8N5hWzHar85Pgyz5RwLvNQ--