On Wed, Jun 15, 2016 at 12:09 PM, Jimmy <jimmyj...@gmail.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? β
