Re: pg_isready features

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Jimmy <jimmyjack(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_isready features
Date: 2016-06-15 16:30:31
Message-ID: CAKFQuwZZ6ECxPcud4Byo90OuMUREv7i9L8CFfaBhGgwUk8D8RA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?
​

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jimmy 2016-06-15 16:40:12 Re: pg_isready features
Previous Message Robert Haas 2016-06-15 16:15:07 Re: An extra error for client disconnection on Windows