Subject: pgping?

From: Ron Watkins <[email-masked]>
Date: Thu, 18 Sep 2025 13:46:15 -0700

How do you install pgping on RHEL 9?
It doesn't appear to come with the distribution.
Is there some specific repo you need to use?

-- 
Ron Watkins, K7DOG
602.743.5272

---

From: Ron Johnson <[email-masked]>
Date: Fri, 19 Sep 2025 00:00:37 -0400

> Is there some specific repo you need to use?

Is it in the RHEL 8 repo?

What does it do that ncat and psql don't do?

Test_PG1() { nc -zw5 $1 5432 &> /dev/null ; }
Test_PG2() { psql -h $1 -XAtqc "select version()" &> /dev/null ; }

Test_PG1 example.com || { echo "Server inaccessible."; do_something; }

-- 
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

---

From: Tom Lane <[email-masked]>
Date: Fri, 19 Sep 2025 00:06:42 -0400

> What does it do that ncat and psql don't do?

pg_isready might be what the OP wants.

			regards, tom lane

---

From: Ron Johnson <[email-masked]>
Date: Fri, 19 Sep 2025 00:09:35 -0400

> pg_isready might be what the OP wants.

Is that a wrapper around PQping?

---

From: "David G. Johnston" <[email-masked]>
Date: Thu, 18 Sep 2025 21:17:50 -0700

> Is that a wrapper around PQping?

Yes.

https://github.com/postgres/postgres/blob/master/src/bin/scripts/pg_isready.c

David J.

---

From: Gunnar <[email-masked]>
Date: Fri, 12 Dec 2025 17:41:24 +0100

> pg_isready might be what the OP wants.
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.

---

From: "David G. Johnston" <[email-masked]>
Date: Sat, 13 Dec 2025 07:54:35 -0700

On Friday, December 12, 2025, Gunnar <[email-masked]> wrote:

> 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.

David J.

---

From: Tom Lane <[email-masked]>
Date: Sat, 13 Dec 2025 10:59:35 -0500

> the database you want to address does not exist.

If you want to see whether you can log in, then try to log in, using
psql or pretty much any other client.  That is not the problem that
pg_isready seeks to solve.

			regards, tom lane

---

From: Ron Johnson <[email-masked]>
Date: Sat, 13 Dec 2025 12:12:04 -0500

> which means nobody cares.

pg_isready is "ncat -zv $host 5432" for systems which don't have ncat
installed.  No/few Linux systems meet that criterion, but Windows systems
might.

---

From: "David G. Johnston" <[email-masked]>
Date: Sat, 13 Dec 2025 11:19:47 -0700

On Saturday, December 13, 2025, Ron Johnson <[email-masked]> wrote:
> installed.

Pretty sure this is also an incorrect, or at least incomplete statement.
 pg_isready uses the PostgreSQL wire protocol to make a better
determination as to readiness than ncat does.  People are just complaining
that it doesn’t go further than it does.  They see “user” and “database”
and misinterpret why those options exist.

David J.

---

From: Gunnar <[email-masked]>
Date: Sat, 13 Dec 2025 19:22:08 +0100

On 12/13/25 15:54, David G. Johnston 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

---

From: Ron Johnson <[email-masked]>
Date: Sat, 13 Dec 2025 17:27:00 -0500

> and misinterpret why those options exist.

We've had this discussion before: people see the --dbname and --username
options, then quite reasonably think "ah, those options must mean you can
test whether a specific database and/or role can connect; otherwise, why
the heck would you put them in the --help output?"

Bottom line: the purpose of --dbname is to specify a database name; the
purpose of --username is to specify a username.  Having them in the --help
output *misleads the user*.

---

From: "David G. Johnston" <[email-masked]>
Date: Sat, 13 Dec 2025 22:59:44 -0700

> output *misleads the user*.
Yes, here.

https://www.postgresql.org/message-id/flat/CANzqJaCSbqU3QUqMhfv5ivYww%3DJQNwyYnKWnEJoO_onCiCrhSg%40mail.gmail.com#3c4b13e8cf1116697e7e7338047728c5

It's unfortunate that the default assumption about those options is
incorrect and one needs to read the notes to understand their purpose.

David J.

---

From: "David G. Johnston" <[email-masked]>
Date: Sun, 14 Dec 2025 05:54:12 -0700

On Saturday, December 13, 2025, Gunnar <[email-masked]> wrote:

> 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.
>

As I wrote in the other thread while rephrasing what the docs say: it
avoids an inconsequential error message in the server log since the backend
protocol requires any connection attempt to include those fields and
sometime the defaults aren’t correct.

David J,

---

From: "David G. Johnston" <[email-masked]>
Date: Sun, 14 Dec 2025 06:00:54 -0700

On Saturday, December 13, 2025, Gunnar <[email-masked]> wrote:
>
> as the aspiration, or maybe even commitment to that feature.
>
>
The amount of additional effort here, to meet such a theoretical
commitment, is so small that this interpretation seems extremely unlikely.
It was a deliberate choice that “is cluster running” not require any
particular element in that cluster to exist.

David J.