Re: pg_isready features

(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

On Wed, Jun 15, 2016 at 9:30 AM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Wed, Jun 15, 2016 at 12:09 PM, Jimmy <jimmyjack(at)gmail(dot)com> wrote:
>
>> 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?
> ​
>
>