[PATCH] pg_isready (was: [WIP] pg_ping utility)
Changing up the subject line because this is no longer a work in
progress nor is it pg_ping anymore.
On Sun, Jan 20, 2013 at 10:36 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
On 01/21/2013 11:26 AM, Robert Haas wrote:
On Sun, Jan 20, 2013 at 2:59 PM, Phil Sorber <phil@omniti.com> wrote:
Ok. I can add something to the notes section of the docs. I can also
add some code comments for this and for grabbing the default params.Sounds good.
I added the code comments, but realized it was already in the docs. I
will provide a separate patch for the PQping docs.
I also added the handling of extra params as Robert suggested.
Oh, I see. Is it really important to have the host and port in the
output, or should we trim that down to just e.g. "accepting
connections"? It seems useful to have that if a human is looking at
the output, but maybe not if a machine is looking at the output. And
if somebody doesn't want it, getting rid of it with sed or awk is
nontrivial - imagine:pg_isready -d "/tmp:5432 - accepting connections"
If you are scripting I'd assume you would use the return code value.
It might be reasonable to make adding the host and port the verbose
method and have just "accepting connections" as the default output,
but my concern there is a misdiagnosis because someone doesn't realize
what server they are connecting to. This way they can't miss it and
they don't have to add another command line option to get that output.It's a fair concern. Does anyone else have an opinion on this?
I have a strong view that the host and port *should* be printed in output.
One of the most common issues on Stack Overflow questions from new users
is with "I can't connect" problems that turn out to be them connecting
to the wrong host, port, or socket path.It is absolutely vital that the unix socket path being used be printed
if unix socket connections are tested, as Mac OS X's insane setup means
that PostgreSQL tool builds on that platform regularly use the system
libpq not the user-installed PostgreSQL's libpq, and it defaults to a
different socket path. If users use pg_ping to verify that their
PostgreSQL instance is running it'll use the user-installed libpq -
fine, that's what we want. But the user will then wonder why the heck
Ruby on Rails's `pg' gem reports it can't connect to the unix socket.
They can't compare the unix socket paths printed in the error message if
pg_ping doesn't show it.I would like to see pg_ping produce a similar error to psql on
connection failure.
As stated above this is no longer called pg_ping. Probably should have
switched the subject line a while ago.
I've left it outputting the host and port as default.
Also, we went over a lot of iterations on how the errors should look.
I am hesitant to change that now. I think the current errors are good
because not being able to connect isn't necessarily an unexpected
outcome like it is for psql.
Show quoted text
$ psql -p 9999
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.9999"?$ psql -h localhost -p 9999
psql: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 9999?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 9999?--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Mon, Jan 21, 2013 at 12:23 PM, Phil Sorber <phil@omniti.com> wrote:
Changing up the subject line because this is no longer a work in
progress nor is it pg_ping anymore.
OK, I committed this. However, I have one suggestion. Maybe it would
be a good idea to add a -c or -t option that sets the connect_timeout
parameter. Because:
[rhaas pgsql]$ pg_isready -h www.google.com
<grows old, dies>
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 23, 2013 at 11:07 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jan 21, 2013 at 12:23 PM, Phil Sorber <phil@omniti.com> wrote:
Changing up the subject line because this is no longer a work in
progress nor is it pg_ping anymore.OK, I committed this. However, I have one suggestion. Maybe it would
be a good idea to add a -c or -t option that sets the connect_timeout
parameter. Because:[rhaas pgsql]$ pg_isready -h www.google.com
<grows old, dies>
Oh, hrmm. Yes, I will address that with a follow up patch. I guess in
my testing I was using a host that responded properly with port
unreachable or TCP RST or something.
Do you think we should have a default timeout, or only have one if
specified at the command line?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Phil Sorber <phil@omniti.com> writes:
On Wed, Jan 23, 2013 at 11:07 AM, Robert Haas <robertmhaas@gmail.com> wrote:
[rhaas pgsql]$ pg_isready -h www.google.com
<grows old, dies>
Do you think we should have a default timeout, or only have one if
specified at the command line?
+1 for default timeout --- if this isn't like "ping" where you are
expecting to run indefinitely, I can't see that it's a good idea for it
to sit very long by default, in any circumstance.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 23, 2013 at 12:27:45PM -0500, Tom Lane wrote:
Phil Sorber <phil@omniti.com> writes:
On Wed, Jan 23, 2013 at 11:07 AM, Robert Haas <robertmhaas@gmail.com> wrote:
[rhaas pgsql]$ pg_isready -h www.google.com
<grows old, dies>Do you think we should have a default timeout, or only have one if
specified at the command line?+1 for default timeout --- if this isn't like "ping" where you are
expecting to run indefinitely, I can't see that it's a good idea for it
to sit very long by default, in any circumstance.
FYI, the pg_ctl -w (wait) default is 60 seconds:
from pg_ctl.c:
#define DEFAULT_WAIT 60
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Jan 23, 2013 at 12:27:45PM -0500, Tom Lane wrote:
Phil Sorber <phil@omniti.com> writes:
On Wed, Jan 23, 2013 at 11:07 AM, Robert Haas <robertmhaas@gmail.com> wrote:
[rhaas pgsql]$ pg_isready -h www.google.com
<grows old, dies>Do you think we should have a default timeout, or only have one if
specified at the command line?+1 for default timeout --- if this isn't like "ping" where you are
expecting to run indefinitely, I can't see that it's a good idea for it
to sit very long by default, in any circumstance.FYI, the pg_ctl -w (wait) default is 60 seconds:
from pg_ctl.c:
#define DEFAULT_WAIT 60
Great. That is what I came to on my own as well. Figured that might be
a sticking point, but as there is precedent, I'm happy with it.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 23, 2013 at 02:50:01PM -0500, Phil Sorber wrote:
On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Jan 23, 2013 at 12:27:45PM -0500, Tom Lane wrote:
Phil Sorber <phil@omniti.com> writes:
On Wed, Jan 23, 2013 at 11:07 AM, Robert Haas <robertmhaas@gmail.com> wrote:
[rhaas pgsql]$ pg_isready -h www.google.com
<grows old, dies>Do you think we should have a default timeout, or only have one if
specified at the command line?+1 for default timeout --- if this isn't like "ping" where you are
expecting to run indefinitely, I can't see that it's a good idea for it
to sit very long by default, in any circumstance.FYI, the pg_ctl -w (wait) default is 60 seconds:
from pg_ctl.c:
#define DEFAULT_WAIT 60
Great. That is what I came to on my own as well. Figured that might be
a sticking point, but as there is precedent, I'm happy with it.
Yeah, being able to point to precedent is always helpful.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 23, 2013 at 2:51 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Jan 23, 2013 at 02:50:01PM -0500, Phil Sorber wrote:
On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Jan 23, 2013 at 12:27:45PM -0500, Tom Lane wrote:
Phil Sorber <phil@omniti.com> writes:
On Wed, Jan 23, 2013 at 11:07 AM, Robert Haas <robertmhaas@gmail.com> wrote:
[rhaas pgsql]$ pg_isready -h www.google.com
<grows old, dies>Do you think we should have a default timeout, or only have one if
specified at the command line?+1 for default timeout --- if this isn't like "ping" where you are
expecting to run indefinitely, I can't see that it's a good idea for it
to sit very long by default, in any circumstance.FYI, the pg_ctl -w (wait) default is 60 seconds:
from pg_ctl.c:
#define DEFAULT_WAIT 60
Great. That is what I came to on my own as well. Figured that might be
a sticking point, but as there is precedent, I'm happy with it.Yeah, being able to point to precedent is always helpful.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com+ It's impossible for everything to be true. +
Attached is the patch to add a connect_timeout.
I also factored out the setting of user and dbname from the default
gathering loop as we only need host and port defaults and made more
sense to handle user/dbname in the same area of the code as
connect_timeout. This was something mentioned by Robert upthread.
This also coincidentally fixes a bug in the size of the keywords and
values arrays. Must have added an option during review and not
extended that array. Is there a best practice to making sure that
doesn't happen in the future? I was thinking define MAX_PARAMS and
then setting the array size to MAX_PARAMS+1 and then checking in the
getopt loop to see how many params we expect to process and erroring
if we are doing to many, but that only works at runtime.
One other thing I noticed while refactoring the defaults gathering
code. If someone passes in a connect string for dbname, we output the
wrong info at the end. This is not addressed in this patch because I
wanted to get some feedback before fixing and make a separate patch. I
see the only real option being to use PQconninfoParse to get the
params from the connect string. If someone passes in a connect string
via dbname should that have precedence over other values passed in via
individual command line options? Should ordering of the command line
options matter?
For example if someone did: pg_isready -h foo -d "host=bar port=4321" -p 1234
What should the connection parameters be?
Attachments:
pg_isready_timeout.diffapplication/octet-stream; name=pg_isready_timeout.diffDownload+35-52
Phil Sorber <phil@omniti.com> writes:
On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Jan 23, 2013 at 12:27:45PM -0500, Tom Lane wrote:
+1 for default timeout --- if this isn't like "ping" where you are
expecting to run indefinitely, I can't see that it's a good idea for it
to sit very long by default, in any circumstance.
FYI, the pg_ctl -w (wait) default is 60 seconds:
Great. That is what I came to on my own as well. Figured that might be
a sticking point, but as there is precedent, I'm happy with it.
I'm not sure that's a relevant precedent at all. What that number is
is the time that pg_ctl will wait around for the postmaster to start or
stop before reporting a problem --- and in either case, a significant
delay (multiple seconds) is not surprising, because of crash-recovery
work, shutdown checkpointing, etc. For pg_isready, you'd expect to get
a response more or less instantly, wouldn't you? Personally, I'd decide
that pg_isready is broken if it didn't give me an answer in a couple of
seconds, much less a minute.
What I had in mind was a default timeout of maybe 3 or 4 seconds...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 23, 2013 at 6:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Phil Sorber <phil@omniti.com> writes:
On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Jan 23, 2013 at 12:27:45PM -0500, Tom Lane wrote:
+1 for default timeout --- if this isn't like "ping" where you are
expecting to run indefinitely, I can't see that it's a good idea for it
to sit very long by default, in any circumstance.FYI, the pg_ctl -w (wait) default is 60 seconds:
Great. That is what I came to on my own as well. Figured that might be
a sticking point, but as there is precedent, I'm happy with it.I'm not sure that's a relevant precedent at all. What that number is
is the time that pg_ctl will wait around for the postmaster to start or
stop before reporting a problem --- and in either case, a significant
delay (multiple seconds) is not surprising, because of crash-recovery
work, shutdown checkpointing, etc. For pg_isready, you'd expect to get
a response more or less instantly, wouldn't you? Personally, I'd decide
that pg_isready is broken if it didn't give me an answer in a couple of
seconds, much less a minute.What I had in mind was a default timeout of maybe 3 or 4 seconds...
I was thinking that if it was in a script you wouldn't care if it was
60 seconds. If it was at the command line you would ^C it much
earlier. I think the default linux TCP connection timeout is around 20
seconds. My feeling is everyone is going to have a differing opinion
on this, which is why I was hoping that some good precedent existed.
I'm fine with 3 or 4, whatever can be agreed upon.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jan 24, 2013 at 8:47 AM, Phil Sorber <phil@omniti.com> wrote:
On Wed, Jan 23, 2013 at 6:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Phil Sorber <phil@omniti.com> writes:
On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Jan 23, 2013 at 12:27:45PM -0500, Tom Lane wrote:
+1 for default timeout --- if this isn't like "ping" where you are
expecting to run indefinitely, I can't see that it's a good idea for it
to sit very long by default, in any circumstance.FYI, the pg_ctl -w (wait) default is 60 seconds:
Great. That is what I came to on my own as well. Figured that might be
a sticking point, but as there is precedent, I'm happy with it.I'm not sure that's a relevant precedent at all. What that number is
is the time that pg_ctl will wait around for the postmaster to start or
stop before reporting a problem --- and in either case, a significant
delay (multiple seconds) is not surprising, because of crash-recovery
work, shutdown checkpointing, etc. For pg_isready, you'd expect to get
a response more or less instantly, wouldn't you? Personally, I'd decide
that pg_isready is broken if it didn't give me an answer in a couple of
seconds, much less a minute.What I had in mind was a default timeout of maybe 3 or 4 seconds...
I was thinking that if it was in a script you wouldn't care if it was
60 seconds. If it was at the command line you would ^C it much
earlier. I think the default linux TCP connection timeout is around 20
seconds. My feeling is everyone is going to have a differing opinion
on this, which is why I was hoping that some good precedent existed.
I'm fine with 3 or 4, whatever can be agreed upon.
+1 with 3 or 4 secounds.
Aside from this issue, I have one minor comment. ISTM you need to
add the following line to the end of the help message. This line has
been included in the help message of all the other client commands.
Report bugs to <pgsql-bugs@postgresql.org>.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 23, 2013 at 8:12 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Thu, Jan 24, 2013 at 8:47 AM, Phil Sorber <phil@omniti.com> wrote:
On Wed, Jan 23, 2013 at 6:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Phil Sorber <phil@omniti.com> writes:
On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Jan 23, 2013 at 12:27:45PM -0500, Tom Lane wrote:
+1 for default timeout --- if this isn't like "ping" where you are
expecting to run indefinitely, I can't see that it's a good idea for it
to sit very long by default, in any circumstance.FYI, the pg_ctl -w (wait) default is 60 seconds:
Great. That is what I came to on my own as well. Figured that might be
a sticking point, but as there is precedent, I'm happy with it.I'm not sure that's a relevant precedent at all. What that number is
is the time that pg_ctl will wait around for the postmaster to start or
stop before reporting a problem --- and in either case, a significant
delay (multiple seconds) is not surprising, because of crash-recovery
work, shutdown checkpointing, etc. For pg_isready, you'd expect to get
a response more or less instantly, wouldn't you? Personally, I'd decide
that pg_isready is broken if it didn't give me an answer in a couple of
seconds, much less a minute.What I had in mind was a default timeout of maybe 3 or 4 seconds...
I was thinking that if it was in a script you wouldn't care if it was
60 seconds. If it was at the command line you would ^C it much
earlier. I think the default linux TCP connection timeout is around 20
seconds. My feeling is everyone is going to have a differing opinion
on this, which is why I was hoping that some good precedent existed.
I'm fine with 3 or 4, whatever can be agreed upon.+1 with 3 or 4 secounds.
Aside from this issue, I have one minor comment. ISTM you need to
add the following line to the end of the help message. This line has
been included in the help message of all the other client commands.Report bugs to <pgsql-bugs@postgresql.org>.
Ok, I set the default timeout to 3 seconds, added the bugs email to
the help, and also added docs that I forgot last time.
Also, still hoping to get some feedback on my other issues.
Thanks.
Show quoted text
Regards,
--
Fujii Masao
Attachments:
pg_isready_timeout_v2.diffapplication/octet-stream; name=pg_isready_timeout_v2.diffDownload+48-52
On Fri, Jan 25, 2013 at 1:45 AM, Phil Sorber <phil@omniti.com> wrote:
On Wed, Jan 23, 2013 at 8:12 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Thu, Jan 24, 2013 at 8:47 AM, Phil Sorber <phil@omniti.com> wrote:
On Wed, Jan 23, 2013 at 6:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Phil Sorber <phil@omniti.com> writes:
On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Jan 23, 2013 at 12:27:45PM -0500, Tom Lane wrote:
+1 for default timeout --- if this isn't like "ping" where you are
expecting to run indefinitely, I can't see that it's a good idea for it
to sit very long by default, in any circumstance.FYI, the pg_ctl -w (wait) default is 60 seconds:
Great. That is what I came to on my own as well. Figured that might be
a sticking point, but as there is precedent, I'm happy with it.I'm not sure that's a relevant precedent at all. What that number is
is the time that pg_ctl will wait around for the postmaster to start or
stop before reporting a problem --- and in either case, a significant
delay (multiple seconds) is not surprising, because of crash-recovery
work, shutdown checkpointing, etc. For pg_isready, you'd expect to get
a response more or less instantly, wouldn't you? Personally, I'd decide
that pg_isready is broken if it didn't give me an answer in a couple of
seconds, much less a minute.What I had in mind was a default timeout of maybe 3 or 4 seconds...
I was thinking that if it was in a script you wouldn't care if it was
60 seconds. If it was at the command line you would ^C it much
earlier. I think the default linux TCP connection timeout is around 20
seconds. My feeling is everyone is going to have a differing opinion
on this, which is why I was hoping that some good precedent existed.
I'm fine with 3 or 4, whatever can be agreed upon.+1 with 3 or 4 secounds.
Aside from this issue, I have one minor comment. ISTM you need to
add the following line to the end of the help message. This line has
been included in the help message of all the other client commands.Report bugs to <pgsql-bugs@postgresql.org>.
Ok, I set the default timeout to 3 seconds, added the bugs email to
the help, and also added docs that I forgot last time.
Thanks!
Also, still hoping to get some feedback on my other issues.
set_pglocale_pgservice() should be called?
I think that the command name (i.e., pg_isready) should be given to
PQpingParams() as fallback_application_name. Otherwise, the server
by default uses "unknown" as the application name of pg_isready.
It's undesirable.
Why isn't the following message output only when invalid option is
specified?
Try \"%s --help\" for more information.
When the conninfo string including the hostname or port number is
specified in -d option, pg_isready displays the wrong information
as follows.
$ pg_isready -d "port=9999"
/tmp:5432 - no response
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jan 24, 2013 at 1:12 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
set_pglocale_pgservice() should be called?
I think that the command name (i.e., pg_isready) should be given to
PQpingParams() as fallback_application_name. Otherwise, the server
by default uses "unknown" as the application name of pg_isready.
It's undesirable.Why isn't the following message output only when invalid option is
specified?Try \"%s --help\" for more information.
I've updated the patch to address these three issues. Attached.
When the conninfo string including the hostname or port number is
specified in -d option, pg_isready displays the wrong information
as follows.$ pg_isready -d "port=9999"
/tmp:5432 - no response
This is what i asked about in my previous email about precedence of
the parameters. I can parse that with PQconninfoParse, but what are
the rules for merging both individual and conninfo params together?
For example if someone did: pg_isready -h foo -d "host=bar port=4321" -p 1234
What should the connection parameters be?
Show quoted text
Regards,
--
Fujii Masao
Attachments:
pg_isready_timeout_v3.diffapplication/octet-stream; name=pg_isready_timeout_v3.diffDownload+53-55
On Fri, Jan 25, 2013 at 4:10 AM, Phil Sorber <phil@omniti.com> wrote:
On Thu, Jan 24, 2013 at 1:12 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
set_pglocale_pgservice() should be called?
I think that the command name (i.e., pg_isready) should be given to
PQpingParams() as fallback_application_name. Otherwise, the server
by default uses "unknown" as the application name of pg_isready.
It's undesirable.Why isn't the following message output only when invalid option is
specified?Try \"%s --help\" for more information.
I've updated the patch to address these three issues. Attached.
When the conninfo string including the hostname or port number is
specified in -d option, pg_isready displays the wrong information
as follows.$ pg_isready -d "port=9999"
/tmp:5432 - no responseThis is what i asked about in my previous email about precedence of
the parameters. I can parse that with PQconninfoParse, but what are
the rules for merging both individual and conninfo params together?
If I read conninfo_array_parse() correctly, PQpingParams() prefer the
option which is set to its keyword array later.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello
We now haw to solve small puppet issue, because our puppets try to
start server too early, when old instance live still.
Maybe some new parameter - is_done can be useful.
Regards
Pavel
When the conninfo string including the hostname or port number is
specified in -d option, pg_isready displays the wrong information
as follows.$ pg_isready -d "port=9999"
/tmp:5432 - no responseThis is what i asked about in my previous email about precedence of
the parameters. I can parse that with PQconninfoParse, but what are
the rules for merging both individual and conninfo params together?If I read conninfo_array_parse() correctly, PQpingParams() prefer the
option which is set to its keyword array later.Regards,
--
Fujii Masao--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jan 26, 2013 at 4:02 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hello
We now haw to solve small puppet issue, because our puppets try to
start server too early, when old instance live still.Maybe some new parameter - is_done can be useful.
What about something like:
pg_isready; while [ $? -ne 2 ]; do sleep 1; pg_isready; done
Perhaps with a counter to break out of the loop after some number of attempts.
Regards
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2013/1/26 Phil Sorber <phil@omniti.com>:
On Sat, Jan 26, 2013 at 4:02 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hello
We now haw to solve small puppet issue, because our puppets try to
start server too early, when old instance live still.Maybe some new parameter - is_done can be useful.
What about something like:
pg_isready; while [ $? -ne 2 ]; do sleep 1; pg_isready; done
it is not enough - server is done in a moment, where can be started
again - or when we can do safe copy of database data directory.
Regards
Pavel
Perhaps with a counter to break out of the loop after some number of attempts.
Regards
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jan 26, 2013 at 11:53 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
2013/1/26 Phil Sorber <phil@omniti.com>:
On Sat, Jan 26, 2013 at 4:02 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hello
We now haw to solve small puppet issue, because our puppets try to
start server too early, when old instance live still.Maybe some new parameter - is_done can be useful.
What about something like:
pg_isready; while [ $? -ne 2 ]; do sleep 1; pg_isready; doneit is not enough - server is done in a moment, where can be started
again - or when we can do safe copy of database data directory.
I guess i am not completely understanding the case you are trying to
solve. Can you explain a bit further?
Regards
Pavel
Perhaps with a counter to break out of the loop after some number of attempts.
Regards
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2013/1/26 Phil Sorber <phil@omniti.com>:
On Sat, Jan 26, 2013 at 11:53 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
2013/1/26 Phil Sorber <phil@omniti.com>:
On Sat, Jan 26, 2013 at 4:02 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hello
We now haw to solve small puppet issue, because our puppets try to
start server too early, when old instance live still.Maybe some new parameter - is_done can be useful.
What about something like:
pg_isready; while [ $? -ne 2 ]; do sleep 1; pg_isready; doneit is not enough - server is done in a moment, where can be started
again - or when we can do safe copy of database data directory.I guess i am not completely understanding the case you are trying to
solve. Can you explain a bit further?
We use puppets and due some simplification we cannot to use reload
when configuration is changed. Our puppets has not enough intelligence
to understand when is reload enough and when is restart necessary. So
any change to configuration require restarting postgres. I don't know
why "service restart" are not used. I believe so our puppet guru know
it. It just do sequence STOP:START Now puppets are "smart" and able
to wait for time, when server is ready. But there are missing simple
test if server is really done and I see a error messages related to
too early try to start. So some important feature can be verification
so server is really done.
We can do it with test on pid file now - and probably we will use it.
But I see so this is similar use case (in opposite direction)
Regards
Pavel
Regards
Pavel
Perhaps with a counter to break out of the loop after some number of attempts.
Regards
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
