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)

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

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

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

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