Re: Is the pg_isready database name relevant?

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.

David J.