Re: [HACKERS] pg_isready features

2016-06-17 Thread Craig Ringer
On 16 June 2016 at 00:40, Jimmy  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


Re: [HACKERS] pg_isready features

2016-06-15 Thread Jimmy
yup, it does for (1)

:-)





On Wed, Jun 15, 2016 at 9:53 AM Imre Samu  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?
> 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

2016-06-15 Thread Imre Samu
>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

2016-06-15 Thread Joshua D. Drake

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

2016-06-15 Thread Jimmy
(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, Jimmy  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?
> ​
>
>


Re: [HACKERS] pg_isready features

2016-06-15 Thread David G. Johnston
On Wed, Jun 15, 2016 at 12:09 PM, Jimmy  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?
​


[HACKERS] pg_isready features

2016-06-15 Thread 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!