(1) I can (and do) use psql, pg_isready seems lighter and since it already supports credentials and DB name, I see very little harm for pg_isready to say back whether user logged IN or not using these credentials.
(2) timeout is not the same - timeout does not retry, its a simple timeout in case connection hangs, try it
Not sure if this was discussed in the past and decided it does not belong to pg_isready utility....
I am using pg_isready in dockerized development environment as part of docker-compose. Simply say I have POSTGRES container and APP container. I use pg_isready inside app container and wait till postgres is ready to accept connections before app starts.
There are two features which would make this a bit smoother and better.
1. enforce login
This could be optional and turned off by default. Basically if user supplies username/database as part of pg_isready call and the login fails (for whatever reason), pg_isready should fail.
Why I need it? There is tiny window between postgres being ready to accept connections and final scripts which create initial user/database. Ideally having option to say "postgres is ready after specific user can login to specific database" would be ideal. Again, this can be optional and turned off by default.
It shouldn't have to enforce login if there is a way for the server to communicate ready or not ready for login without requiring credentials to actually be supplied. I guess it would be more effort and invasive. Are you trying to avoid psql here?
2. retry
This is something I can do via unix script, but ideally it would be nice if there would be retry mechanism. For example if I say retry=30 then pg_isready would try 30x with x seconds pause in between and fail only after 30 retries. This could use default retry=0 (current behavior)
And the value of this instead of setting a timeout 30x higher is?