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!
On Wed, Jun 15, 2016 at 12:09 PM, Jimmy <jimmyjack@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?
(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:
Show quoted text
On Wed, Jun 15, 2016 at 12:09 PM, Jimmy <jimmyjack@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?
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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?
see :
https://github.com/docker-library/postgres/blob/master/9.5/docker-entrypoint.sh#L50
*# internal start of server in order to allow set-up using psql-client *
*# does not listen on external TCP/IP and waits until start finishes*
*gosu postgres pg_ctl -D "$PGDATA" -o "-c listen_addresses='localhost'" *
*.....*
more info: https://github.com/docker-library/postgres/issues/146
2016-06-15 18:09 GMT+02:00 Jimmy <jimmyjack@gmail.com>:
Show quoted text
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!
yup, it does for (1)
:-)
On Wed, Jun 15, 2016 at 9:53 AM Imre Samu <pella.samu@gmail.com> wrote:
Show quoted text
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 canlogin to specific database" would be ideal.
temporary - the official docker-postgres solution is not OK?
see :
https://github.com/docker-library/postgres/blob/master/9.5/docker-entrypoint.sh#L50*# internal start of server in order to allow set-up using psql-client *
*# does not listen on external TCP/IP and waits until start finishes*
*gosu postgres pg_ctl -D "$PGDATA" -o "-c listen_addresses='localhost'" **.....*
more info: https://github.com/docker-library/postgres/issues/146
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 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!
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.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services