Subject: Is the pg_isready database name relevant?

From: Ron Johnson <[email-masked]>
Date: Mon, 24 Nov 2025 11:27:57 -0500

The "-d, --dbname=DBNAME" option is mentioned in --help output, but
pg_isready ignores nonexistent databases.

$ psql -V
psql (PostgreSQL) 17.6
$ pg_isready -d blarge -h BBOSLBXPGS402
BBOSLBXPGS402:5432 - accepting connections

Is this an application bug, a minor doc bug or am I missing something?

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

---

From: "David G. Johnston" <[email-masked]>
Date: Mon, 24 Nov 2025 10:30:41 -0600

> Is this an application bug, a minor doc bug or am I missing something?

It’s documented in the Notes section.

David J.

---

From: Ron Johnson <[email-masked]>
Date: Mon, 24 Nov 2025 11:38:59 -0500

> It’s documented in the Notes section.

That seems odd.  Why mention an option in --help if the option isn't needed?

---

From: "David G. Johnston" <[email-masked]>
Date: Mon, 24 Nov 2025 10:45:53 -0600

> That seems odd.  Why mention an option in --help if the option isn't

Because it exists - and I figure most people should use it to not put
spurious errors into the logs.

David J.

---

From: Ron Johnson <[email-masked]>
Date: Mon, 24 Nov 2025 11:52:58 -0500

> spurious errors into the logs.

The person on the client side isn't thinking about what's going in the PG
server's logs.

This is something that *should* be fixed.  Very low priority, after the
data corruption and feature bugs, and useful new features added, but either
return an error code if the client user doesn't have access to that
database, or remove the option.

---

From: "David G. Johnston" <[email-masked]>
Date: Mon, 24 Nov 2025 12:18:04 -0600

> database, or remove the option.

It reports whether the cluster is ready, not any specific database or for
any specific user.  It works just fine for its intent.  Sure, it could be
modified to also do something different.  But you haven't explained why
that would be a worthwhile use of effort.  All I'm seeing it admittedly a
slightly non-intuitative specification that does require reading and some
degree of caring on the part of the user.  And probably some recognition
that it works this way because the backend protocol doesn't allow for those
values to be made optional and so the current implementation is a bit of a
hack to get around that fact.

David J.

---

From: Tom Lane <[email-masked]>
Date: Mon, 24 Nov 2025 13:30:52 -0500

Ron Johnson <[email-masked]> writes:
> This is something that *should* be fixed.

What do you think a fix would consist of?  The program is working
according to the design goals that were set for it.  In particular,
the objective is to test whether the server is up --- and if it
answers back with 'database "foo" does not exist', then yes it's
up.  But at the same time, people might not wish to clutter their
server log with failed-connection messages, so we provide the
necessary options to make the test connection attempt a valid one.

			regards, tom lane

---

From: Ron Johnson <[email-masked]>
Date: Mon, 24 Nov 2025 13:31:47 -0500

> hack to get around that fact.

"Option exists, is mentioned in --help, but doesn't do anything" is a (very
low priority) bug.  That's plain and simple.

You'd say the same thing about a non-Postgresql program that you use, but
you resist it in the system you're invested in.

---

From: Tom Lane <[email-masked]>
Date: Mon, 24 Nov 2025 13:47:43 -0500

> low priority) bug.  That's plain and simple.

Plain, simple, and wrong.  It does do something.  Maybe not something
you care about, but that could be said of a lot of options.

			regards, tom lane

---

From: Ron Johnson <[email-masked]>
Date: Mon, 24 Nov 2025 13:48:40 -0500

On Mon, Nov 24, 2025 at 1:30 PM Tom Lane <[email-masked]> wrote:

> up.

Remove the database option.

>   But at the same time, people might not wish to clutter their

Be thorough, or be really light.

These two do the exact same thing, but ncat can't generate a spurious log
entry:
pg_isready -h foo || handle error
ncat -zw10 foo 5432 || handle error

while this does a thorough check:
psql -h foo -d bar -U snaggle -qXc "\q" || handle error

And they all execute in the same amount of time.

---

From: "David G. Johnston" <[email-masked]>
Date: Mon, 24 Nov 2025 15:54:19 -0600

On Mon, Nov 24, 2025, 11:32 Ron Johnson <[email-masked]> wrote:

>
>
> "Option exists, is mentioned in --help, but doesn't do anything" is a
> (very low priority) bug.  That's plain and simple.
>

It does exactly what it says it does.  A bug would be operating against the
defined intention which this is not.  Your disagreement with its design
might make it a bug for you personally but not for the project.

Now, if --help doesn't include the notes section maybe we could make it
more clear in each of these optional arguments how they behave directly.
Given you aren't the first to express confusion here - just search the
mailing lists - such a doc tweak would  have a decent chance of going in.

> you resist it in the system you're invested in.

Are you just trolling us now?  It's been made clear what this option does
and you are seeming to just ignore that reality.

David J.