Обсуждение: Is the pg_isready database name relevant?
The "-d, --dbname=DBNAME" option is mentioned in --help output, but pg_isready ignores nonexistent databases.
$ psql -V
psql (PostgreSQL) 17.6
psql (PostgreSQL) 17.6
$ pg_isready -d blarge -h BBOSLBXPGS402
BBOSLBXPGS402:5432 - accepting connections
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!
On Monday, November 24, 2025, Ron Johnson <ronljohnsonjr@gmail.com> wrote:
The "-d, --dbname=DBNAME" option is mentioned in --help output, but pg_isready ignores nonexistent databases.Is this an application bug, a minor doc bug or am I missing something?
It’s documented in the Notes section.
David J.
On Mon, Nov 24, 2025 at 11:30 AM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Monday, November 24, 2025, Ron Johnson <ronljohnsonjr@gmail.com> wrote:The "-d, --dbname=DBNAME" option is mentioned in --help output, but pg_isready ignores nonexistent databases.Is this an application bug, a minor doc bug or am I missing something?It’s documented in the Notes section.
That seems odd. Why mention an option in --help if the option isn't needed?
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
On Monday, November 24, 2025, Ron Johnson <ronljohnsonjr@gmail.com> wrote:
On Mon, Nov 24, 2025 at 11:30 AM David G. Johnston <david.g.johnston@gmail.com> wrote:On Monday, November 24, 2025, Ron Johnson <ronljohnsonjr@gmail.com> wrote:The "-d, --dbname=DBNAME" option is mentioned in --help output, but pg_isready ignores nonexistent databases.Is this an application bug, a minor doc bug or am I missing something?It’s documented in the Notes section.That seems odd. Why mention an option in --help if the option isn't needed?
Because it exists - and I figure most people should use it to not put spurious errors into the logs.
David J.
On Mon, Nov 24, 2025 at 11:45 AM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Monday, November 24, 2025, Ron Johnson <ronljohnsonjr@gmail.com> wrote:On Mon, Nov 24, 2025 at 11:30 AM David G. Johnston <david.g.johnston@gmail.com> wrote:On Monday, November 24, 2025, Ron Johnson <ronljohnsonjr@gmail.com> wrote:The "-d, --dbname=DBNAME" option is mentioned in --help output, but pg_isready ignores nonexistent databases.Is this an application bug, a minor doc bug or am I missing something?It’s documented in the Notes section.That seems odd. Why mention an option in --help if the option isn't needed?Because it exists - and I figure most people should use it to not put 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.
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
On Mon, Nov 24, 2025, 09:53 Ron Johnson <ronljohnsonjr@gmail.com> wrote:
On Mon, Nov 24, 2025 at 11:45 AM David G. Johnston <david.g.johnston@gmail.com> wrote:On Monday, November 24, 2025, Ron Johnson <ronljohnsonjr@gmail.com> wrote:On Mon, Nov 24, 2025 at 11:30 AM David G. Johnston <david.g.johnston@gmail.com> wrote:On Monday, November 24, 2025, Ron Johnson <ronljohnsonjr@gmail.com> wrote:The "-d, --dbname=DBNAME" option is mentioned in --help output, but pg_isready ignores nonexistent databases.Is this an application bug, a minor doc bug or am I missing something?It’s documented in the Notes section.That seems odd. Why mention an option in --help if the option isn't needed?Because it exists - and I figure most people should use it to not put 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.
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.
Ron Johnson <ronljohnsonjr@gmail.com> 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
On Mon, Nov 24, 2025 at 1:18 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Mon, Nov 24, 2025, 09:53 Ron Johnson <ronljohnsonjr@gmail.com> wrote:On Mon, Nov 24, 2025 at 11:45 AM David G. Johnston <david.g.johnston@gmail.com> wrote:On Monday, November 24, 2025, Ron Johnson <ronljohnsonjr@gmail.com> wrote:On Mon, Nov 24, 2025 at 11:30 AM David G. Johnston <david.g.johnston@gmail.com> wrote:On Monday, November 24, 2025, Ron Johnson <ronljohnsonjr@gmail.com> wrote:The "-d, --dbname=DBNAME" option is mentioned in --help output, but pg_isready ignores nonexistent databases.Is this an application bug, a minor doc bug or am I missing something?It’s documented in the Notes section.That seems odd. Why mention an option in --help if the option isn't needed?Because it exists - and I figure most people should use it to not put 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.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.
"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.
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
Ron Johnson <ronljohnsonjr@gmail.com> writes:
> "Option exists, is mentioned in --help, but doesn't do anything" is a (very
> 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
On Mon, Nov 24, 2025 at 1:30 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ron Johnson <ronljohnsonjr@gmail.com> 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.
Remove the database option.
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.
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.
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
On Mon, Nov 24, 2025, 11:32 Ron Johnson <ronljohnsonjr@gmail.com> 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'd say the same thing about a non-Postgresql program that you use, but 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.