Re: [HACKERS] pg_isready features
On 16 June 2016 at 00:40, Jimmywrote: > > (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
Re: [HACKERS] pg_isready features
yup, it does for (1) :-) On Wed, Jun 15, 2016 at 9:53 AM Imre Samuwrote: > >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 : > >> 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! >> >> >> >
Re: [HACKERS] 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: > 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! > > >
Re: [HACKERS] pg_isready features
On 06/15/2016 09:30 AM, David G. Johnston wrote: On Wed, Jun 15, 2016 at 12:09 PM, Jimmy
Re: [HACKERS] 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.johns...@gmail.com> wrote: > On Wed, Jun 15, 2016 at 12:09 PM, Jimmywrote: > >> 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? > > >
Re: [HACKERS] pg_isready features
On Wed, Jun 15, 2016 at 12:09 PM, Jimmywrote: > 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?
[HACKERS] 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!