Re: Is the pg_isready database name relevant?

On Mon, Nov 24, 2025 at 1:18 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Mon, Nov 24, 2025, 09:53 Ron Johnson <ronljohnsonjr(at)gmail(dot)com> wrote:
>
>> On Mon, Nov 24, 2025 at 11:45 AM David G. Johnston <
>> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>>
>>> On Monday, November 24, 2025, Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
>>> wrote:
>>>
>>>> On Mon, Nov 24, 2025 at 11:30 AM David G. Johnston <
>>>> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>>>>
>>>>> On Monday, November 24, 2025, Ron Johnson <ronljohnsonjr(at)gmail(dot)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!