Обсуждение: pg_isready features
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.
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)
thanks a lot!
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 loginThis 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. retryThis 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?
(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.g.johnston@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 loginThis 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. retryThis 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?
On 06/15/2016 09:30 AM, David G. Johnston wrote: > On Wed, Jun 15, 2016 at 12:09 PM, Jimmy <jimmyjack@gmail.com > > *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? Simplicity. JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
>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.
temporary - the official docker-postgres solution is not OK?
>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.
temporary - the official docker-postgres solution is not OK?
# internal start of server in order to allow set-up using psql-client# does not listen on external TCP/IP and waits until start finishesgosu postgres pg_ctl -D "$PGDATA" -o "-c listen_addresses='localhost'"
.....
2016-06-15 18:09 GMT+02:00 Jimmy <jimmyjack@gmail.com>:
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 loginThis 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.2. retryThis 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)thanks a lot!
yup, it does for (1)
:-)
On Wed, Jun 15, 2016 at 9:53 AM Imre Samu <pella.samu@gmail.com> wrote:
>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.temporary - the official docker-postgres solution is not OK?# internal start of server in order to allow set-up using psql-client# does not listen on external TCP/IP and waits until start finishesgosu postgres pg_ctl -D "$PGDATA" -o "-c listen_addresses='localhost'".....2016-06-15 18:09 GMT+02:00 Jimmy <jimmyjack@gmail.com>: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 loginThis 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.2. retryThis 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)thanks a lot!
On 16 June 2016 at 00:40, Jimmy <jimmyjack@gmail.com> wrote:
(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
That threw me recently, too.
If your DB is in recovery, pg_isready with a long timeout won't wait until it's accepting normal user connections or until timeout. There's no way to get that behaviour without a shell script loop or similar.
So yeah, +1 for this.