public inbox for [email protected]
help / color / mirror / Atom feedIs the pg_isready database name relevant?
11+ messages / 3 participants
[nested] [flat]
* Is the pg_isready database name relevant?
@ 2025-11-24 16:27 Ron Johnson <[email protected]>
2025-11-24 16:30 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Ron Johnson @ 2025-11-24 16:27 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>
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!
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Is the pg_isready database name relevant?
2025-11-24 16:27 Is the pg_isready database name relevant? Ron Johnson <[email protected]>
@ 2025-11-24 16:30 ` David G. Johnston <[email protected]>
2025-11-24 16:38 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: David G. Johnston @ 2025-11-24 16:30 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: Pgsql-admin <[email protected]>
On Monday, November 24, 2025, Ron Johnson <[email protected]> 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.
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Is the pg_isready database name relevant?
2025-11-24 16:27 Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:30 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
@ 2025-11-24 16:38 ` Ron Johnson <[email protected]>
2025-11-24 16:45 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Ron Johnson @ 2025-11-24 16:38 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>
On Mon, Nov 24, 2025 at 11:30 AM David G. Johnston <
[email protected]> wrote:
> On Monday, November 24, 2025, Ron Johnson <[email protected]> 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!
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Is the pg_isready database name relevant?
2025-11-24 16:27 Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:30 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:38 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
@ 2025-11-24 16:45 ` David G. Johnston <[email protected]>
2025-11-24 16:52 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: David G. Johnston @ 2025-11-24 16:45 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: Pgsql-admin <[email protected]>
On Monday, November 24, 2025, Ron Johnson <[email protected]> wrote:
> On Mon, Nov 24, 2025 at 11:30 AM David G. Johnston <
> [email protected]> wrote:
>
>> On Monday, November 24, 2025, Ron Johnson <[email protected]>
>> 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.
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Is the pg_isready database name relevant?
2025-11-24 16:27 Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:30 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:38 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:45 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
@ 2025-11-24 16:52 ` Ron Johnson <[email protected]>
2025-11-24 18:18 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 18:30 ` Re: Is the pg_isready database name relevant? Tom Lane <[email protected]>
0 siblings, 2 replies; 11+ messages in thread
From: Ron Johnson @ 2025-11-24 16:52 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>
On Mon, Nov 24, 2025 at 11:45 AM David G. Johnston <
[email protected]> wrote:
> On Monday, November 24, 2025, Ron Johnson <[email protected]> wrote:
>
>> On Mon, Nov 24, 2025 at 11:30 AM David G. Johnston <
>> [email protected]> wrote:
>>
>>> On Monday, November 24, 2025, Ron Johnson <[email protected]>
>>> 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!
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Is the pg_isready database name relevant?
2025-11-24 16:27 Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:30 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:38 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:45 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:52 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
@ 2025-11-24 18:18 ` David G. Johnston <[email protected]>
2025-11-24 18:31 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
1 sibling, 1 reply; 11+ messages in thread
From: David G. Johnston @ 2025-11-24 18:18 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: Pgsql-admin <[email protected]>
On Mon, Nov 24, 2025, 09:53 Ron Johnson <[email protected]> wrote:
> On Mon, Nov 24, 2025 at 11:45 AM David G. Johnston <
> [email protected]> wrote:
>
>> On Monday, November 24, 2025, Ron Johnson <[email protected]>
>> wrote:
>>
>>> On Mon, Nov 24, 2025 at 11:30 AM David G. Johnston <
>>> [email protected]> wrote:
>>>
>>>> On Monday, November 24, 2025, Ron Johnson <[email protected]>
>>>> 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.
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Is the pg_isready database name relevant?
2025-11-24 16:27 Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:30 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:38 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:45 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:52 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 18:18 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
@ 2025-11-24 18:31 ` Ron Johnson <[email protected]>
2025-11-24 18:47 ` Re: Is the pg_isready database name relevant? Tom Lane <[email protected]>
2025-11-24 21:54 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
0 siblings, 2 replies; 11+ messages in thread
From: Ron Johnson @ 2025-11-24 18:31 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>
On Mon, Nov 24, 2025 at 1:18 PM David G. Johnston <
[email protected]> wrote:
> On Mon, Nov 24, 2025, 09:53 Ron Johnson <[email protected]> wrote:
>
>> On Mon, Nov 24, 2025 at 11:45 AM David G. Johnston <
>> [email protected]> wrote:
>>
>>> On Monday, November 24, 2025, Ron Johnson <[email protected]>
>>> wrote:
>>>
>>>> On Mon, Nov 24, 2025 at 11:30 AM David G. Johnston <
>>>> [email protected]> wrote:
>>>>
>>>>> On Monday, November 24, 2025, Ron Johnson <[email protected]>
>>>>> 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!
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Is the pg_isready database name relevant?
2025-11-24 16:27 Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:30 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:38 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:45 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:52 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 18:18 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 18:31 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
@ 2025-11-24 18:47 ` Tom Lane <[email protected]>
1 sibling, 0 replies; 11+ messages in thread
From: Tom Lane @ 2025-11-24 18:47 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: Pgsql-admin <[email protected]>
Ron Johnson <[email protected]> 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
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Is the pg_isready database name relevant?
2025-11-24 16:27 Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:30 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:38 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:45 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:52 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 18:18 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 18:31 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
@ 2025-11-24 21:54 ` David G. Johnston <[email protected]>
1 sibling, 0 replies; 11+ messages in thread
From: David G. Johnston @ 2025-11-24 21:54 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: Pgsql-admin <[email protected]>
On Mon, Nov 24, 2025, 11:32 Ron Johnson <[email protected]> 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.
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Is the pg_isready database name relevant?
2025-11-24 16:27 Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:30 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:38 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:45 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:52 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
@ 2025-11-24 18:30 ` Tom Lane <[email protected]>
2025-11-24 18:48 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
1 sibling, 1 reply; 11+ messages in thread
From: Tom Lane @ 2025-11-24 18:30 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: Pgsql-admin <[email protected]>
Ron Johnson <[email protected]> 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
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Is the pg_isready database name relevant?
2025-11-24 16:27 Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:30 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:38 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:45 ` Re: Is the pg_isready database name relevant? David G. Johnston <[email protected]>
2025-11-24 16:52 ` Re: Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 18:30 ` Re: Is the pg_isready database name relevant? Tom Lane <[email protected]>
@ 2025-11-24 18:48 ` Ron Johnson <[email protected]>
0 siblings, 0 replies; 11+ messages in thread
From: Ron Johnson @ 2025-11-24 18:48 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>
On Mon, Nov 24, 2025 at 1:30 PM Tom Lane <[email protected]> wrote:
> Ron Johnson <[email protected]> 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!
^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2025-11-24 21:54 UTC | newest]
Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-11-24 16:27 Is the pg_isready database name relevant? Ron Johnson <[email protected]>
2025-11-24 16:30 ` David G. Johnston <[email protected]>
2025-11-24 16:38 ` Ron Johnson <[email protected]>
2025-11-24 16:45 ` David G. Johnston <[email protected]>
2025-11-24 16:52 ` Ron Johnson <[email protected]>
2025-11-24 18:18 ` David G. Johnston <[email protected]>
2025-11-24 18:31 ` Ron Johnson <[email protected]>
2025-11-24 18:47 ` Tom Lane <[email protected]>
2025-11-24 21:54 ` David G. Johnston <[email protected]>
2025-11-24 18:30 ` Tom Lane <[email protected]>
2025-11-24 18:48 ` Ron Johnson <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox