pg_isready features

Started by Jimmyover 9 years ago7 messages
#1Jimmy
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!

#2David G. Johnston
david.g.johnston@gmail.com
In reply to: Jimmy (#1)
Re: pg_isready features

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?

#3Jimmy
jimmyjack@gmail.com
In reply to: David G. Johnston (#2)
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.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?

#4Joshua D. Drake
jd@commandprompt.com
In reply to: David G. Johnston (#2)
Re: pg_isready features

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

#5Imre Samu
pella.samu@gmail.com
In reply to: Jimmy (#1)
Re: pg_isready features

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!

#6Jimmy
jimmyjack@gmail.com
In reply to: Imre Samu (#5)
Re: pg_isready features

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 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>:

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!

#7Craig Ringer
craig@2ndquadrant.com
In reply to: Jimmy (#3)
Re: pg_isready features

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