Thread: pg_ctl reports succes when start fails
Hi, I installed 7.4beta5, created a data-dir and tried to start postgresql with pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me "postmaster successfully started", after a fatal error, which looks very confusing. When I use -l for specifying a logfile, I don't even see the error, but only the success-message. Tommi -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de
Tommi Maekitalo <t.maekitalo@epgmbh.de> writes:
> I installed 7.4beta5, created a data-dir and tried to start postgresql with
> pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me
> "postmaster successfully started", after a fatal error, which looks very
> confusing. When I use -l for specifying a logfile, I don't even see the
> error, but only the success-message.
If you don't use -w, then pg_ctl doesn't wait around to see whether the
postmaster started or not. It'd probably be a good idea for it to issue
a less positive message in this case, maybe only "postmaster launched".
I also wonder why -w isn't the default.
regards, tom lane
Tom Lane wrote: >Tommi Maekitalo <t.maekitalo@epgmbh.de> writes: > > >>I installed 7.4beta5, created a data-dir and tried to start postgresql with >>pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me >>"postmaster successfully started", after a fatal error, which looks very >>confusing. When I use -l for specifying a logfile, I don't even see the >>error, but only the success-message. >> >> > >If you don't use -w, then pg_ctl doesn't wait around to see whether the >postmaster started or not. It'd probably be a good idea for it to issue >a less positive message in this case, maybe only "postmaster launched". > >I also wonder why -w isn't the default. > > > It is for stop but not for start/restart, which does seem a bit odd. On a slightly related note, I see that this is still a shell script, as are initlocation, ipcclean and pg_config. I assume these will have to be rewritten in C for the Win32 port? cheers andrew
> If you don't use -w, then pg_ctl doesn't wait around to see whether the > postmaster started or not. It'd probably be a good idea for it to issue > a less positive message in this case, maybe only "postmaster launched". > > I also wonder why -w isn't the default. I've also noticed that on our production 7.3.4 server logging to syslog, that if I change the postgresql.conf to enable log_statement, and then do pg_ctl reload, it works, but then when I disable it again, pg_ctl reload does not cause postgres to pick up the changes. I haven't done too much investigation here in to the exact problem, but there is something odd going on... Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> I've also noticed that on our production 7.3.4 server logging to syslog,
> that if I change the postgresql.conf to enable log_statement, and then
> do pg_ctl reload, it works, but then when I disable it again, pg_ctl
> reload does not cause postgres to pick up the changes.
By "disable" do you mean "turn off", or "comment out again"? The latter
is not going to affect the state of the postmaster ...
regards, tom lane
> By "disable" do you mean "turn off", or "comment out again"? The latter > is not going to affect the state of the postmaster ... The latter...why won't it affect the postmaster state? Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>> By "disable" do you mean "turn off", or "comment out again"? The latter
>> is not going to affect the state of the postmaster ...
> The latter...why won't it affect the postmaster state?
Because it's a *comment*.
regards, tom lane
>>The latter...why won't it affect the postmaster state? > > > Because it's a *comment*. Shouldn't it revert to the default value? Chris
Andrew Dunstan wrote: > Tom Lane wrote: > > >Tommi Maekitalo <t.maekitalo@epgmbh.de> writes: > > > > > >>I installed 7.4beta5, created a data-dir and tried to start postgresql with > >>pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me > >>"postmaster successfully started", after a fatal error, which looks very > >>confusing. When I use -l for specifying a logfile, I don't even see the > >>error, but only the success-message. > >> > >> > > > >If you don't use -w, then pg_ctl doesn't wait around to see whether the > >postmaster started or not. It'd probably be a good idea for it to issue > >a less positive message in this case, maybe only "postmaster launched". > > > >I also wonder why -w isn't the default. > > > > > > > It is for stop but not for start/restart, which does seem a bit odd. > > On a slightly related note, I see that this is still a shell script, as > are initlocation, ipcclean and pg_config. I assume these will have to be > rewritten in C for the Win32 port? OK, I updated the Win32 web page to mention we need a C version of pg_ctl. I don't think we will need pg_config once we have initdb in C, and I don't think it is worth doing initlocation because we need tablespaces. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: > Tommi Maekitalo <t.maekitalo@epgmbh.de> writes: > > I installed 7.4beta5, created a data-dir and tried to start postgresql with > > pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me > > "postmaster successfully started", after a fatal error, which looks very > > confusing. When I use -l for specifying a logfile, I don't even see the > > error, but only the success-message. > > If you don't use -w, then pg_ctl doesn't wait around to see whether the > postmaster started or not. It'd probably be a good idea for it to issue > a less positive message in this case, maybe only "postmaster launched". > > I also wonder why -w isn't the default. The following patch changes the message from "started" to "starting" for non-"-w" starts. I will keep it for 7.5. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: src/bin/pg_ctl/pg_ctl.sh =================================================================== RCS file: /cvsroot/pgsql-server/src/bin/pg_ctl/pg_ctl.sh,v retrieving revision 1.36 diff -c -c -r1.36 pg_ctl.sh *** src/bin/pg_ctl/pg_ctl.sh 14 Aug 2003 18:56:41 -0000 1.36 --- src/bin/pg_ctl/pg_ctl.sh 23 Oct 2003 16:49:56 -0000 *************** *** 399,406 **** fi done $silence_echo echo "done" fi - $silence_echo echo "postmaster successfully started" fi # start or restart exit 0 --- 399,408 ---- fi done $silence_echo echo "done" + $silence_echo echo "postmaster successfully started" + else + $silence_echo echo "postmaster starting" fi fi # start or restart exit 0
Bruce Momjian wrote: >OK, I updated the Win32 web page to mention we need a C version of >pg_ctl. I don't think we will need pg_config once we have initdb in C, >and I don't think it is worth doing initlocation because we need >tablespaces. > I will put it on my todo list (should be simpler than initdb ;-) ). I'll start with a Unix version since I haven't seen the shape of the signalling we are using on Win32 yet. cheers andrew
Tom Lane writes: > I also wonder why -w isn't the default. Because it is not sufficiently reliable in start mode. See source code and archives. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: >Tom Lane writes: > > > >>I also wonder why -w isn't the default. >> >> > >Because it is not sufficiently reliable in start mode. See >source code and archives. > > > I think we can improve -w, though. Here's what the code says about the section where it tries to use psql to determine that the postmaster is up and running: # FIXME: This is horribly misconceived. # 1) If password authentication is set up, the connection will fail. # 2) If a virtual host is set up, the connection may fail. # 3) If network traffic filters are set up tight enough, the connection # may fail. # 4) When no Unix domain sockets are available, the connection will # fail. (Using TCP/IP by default ain't better.) # 5) If the dynamic loader is not set up correctly (for this user/at # this time), psql will fail (to find libpq). # 6) If psql is misconfigured, this may fail. we could provide a password option to handle 1, and in C we can make the connection ourselves using libpq instead of relying on psql to do it for us, which should account for 5 and 6, I think. For the cases of 2, 3 and 4 we can either try to detect it from the configuration settings, or suggest that users will need to use -W for such cases. To me it would be strange to have a setup where no connection from the machine where pg is running is possible, but maybe people do such odd things. We can also try to come up with a better scheme for verifying that we have started properly - I will think about that. cheers andrew
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>>> The latter...why won't it affect the postmaster state?
>>
>> Because it's a *comment*.
> Shouldn't it revert to the default value?
No, not unless you think the postmaster should react to comments in the
postgresql.conf file, which is rather against my idea of a comment.
However, you're not the first to get burnt by this mis-assumption,
so maybe we should do something about it.
The low-tech solution to this would be to stop listing the default
values as commented-out entries, but just make them ordinary uncommented
entries. That way people who think "undoing my edit will revert the
change" would be right.
Or we could try to make it actually work the way you seem to be
expecting. The only implementation I can think of is to reset GUC
variables to defaults just before scanning the .conf file (but only
if their prior value came from the .conf file, which fortunately is
something we keep track of). The trouble with this is that any error
in scanning the .conf file could leave you with unexpectedly reverted
values for later entries, because they'd not be reached.
Or we could just document the behavior better...
regards, tom lane
> Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: > > Shouldn't it revert to the default value? > > No, not unless you think the postmaster should react to comments in the > postgresql.conf file, which is rather against my idea of a comment. > > However, you're not the first to get burnt by this mis-assumption, > so maybe we should do something about it. > > The low-tech solution to this would be to stop listing the default > values as commented-out entries, but just make them ordinary uncommented > entries. That way people who think "undoing my edit will revert the > change" would be right. > > Or we could try to make it actually work the way you seem to be > expecting. The only implementation I can think of is to reset GUC > variables to defaults just before scanning the .conf file ... ------ I have to say we never had any problems or misconception with how it currently works, but if this has to be changed I'd rather vote for the low-tech solution. Mike.
Andrew Dunstan <andrew@dunslane.net> writes:
> We can also try to come up with a better scheme for verifying that we
> have started properly - I will think about that.
There have been previous suggestions for a "pg_ping" functionality, in
which you could simply send a packet to the postmaster and it would
answer back if it's open for business. You can approximate this by
sending a deliberately invalid login packet, but it's not quite the same
thing. I think there were some concerns about security though; check
the archives.
In any case, a C-code pg_ctl could eliminate most of the problems
directly, simply because it wouldn't have to rely on psql.
regards, tom lane
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>We can also try to come up with a better scheme for verifying that we >>have started properly - I will think about that. >> >> > >There have been previous suggestions for a "pg_ping" functionality, in >which you could simply send a packet to the postmaster and it would >answer back if it's open for business. You can approximate this by >sending a deliberately invalid login packet, but it's not quite the same >thing. I think there were some concerns about security though; check >the archives. > >In any case, a C-code pg_ctl could eliminate most of the problems >directly, simply because it wouldn't have to rely on psql. > > > Right. The remaining cases would be fairly much those where the configuration is such that a connection is not possible. My feeling is that if people tie themselves down that tightly then they should also specify "no wait" with pg_ctl - it depends on how much we want to keep backwards compatibility with this behaviour. cheers andrew
> However, you're not the first to get burnt by this mis-assumption, > so maybe we should do something about it. > > The low-tech solution to this would be to stop listing the default > values as commented-out entries, but just make them ordinary uncommented > entries. That way people who think "undoing my edit will revert the > change" would be right. I would be in favour of that way of doing things. I have always found it weird that defaults were commented out... Chris
Re: Defaults for GUC variables (was Re: pg_ctl reports succes when start fails)
From
Manfred Koizar
Date:
On Mon, 27 Oct 2003 10:22:32 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote: >The low-tech solution to this would be to stop listing the default >values as commented-out entries, but just make them ordinary uncommented >entries. Please not. How should we ask a newbie seeking assistance on one of the support lists to show his non-default config settings? ServusManfred
> > We can also try to come up with a better scheme for verifying that > > we have started properly - I will think about that. > > There have been previous suggestions for a "pg_ping" functionality, > in which you could simply send a packet to the postmaster and it > would answer back if it's open for business. You can approximate > this by sending a deliberately invalid login packet, but it's not > quite the same thing. I think there were some concerns about > security though; check the archives. Um, I wrote pg_ping and sent it to -patches but got no comments. http://archives.postgresql.org/pgsql-patches/2003-07/msg00053.php pg_ping is actually the basis for the threaded benchmark program I've got sitting in my tree, but I don't think folks here would look kindly on a -lpthread dependency given how up in the air pg's thread support/testing is at the moment. -sc -- Sean Chittenden
Sean Chittenden wrote: > > > We can also try to come up with a better scheme for verifying that > > > we have started properly - I will think about that. > > > > There have been previous suggestions for a "pg_ping" functionality, > > in which you could simply send a packet to the postmaster and it > > would answer back if it's open for business. You can approximate > > this by sending a deliberately invalid login packet, but it's not > > quite the same thing. I think there were some concerns about > > security though; check the archives. > > Um, I wrote pg_ping and sent it to -patches but got no comments. > > http://archives.postgresql.org/pgsql-patches/2003-07/msg00053.php > > pg_ping is actually the basis for the threaded benchmark program I've > got sitting in my tree, but I don't think folks here would look kindly > on a -lpthread dependency given how up in the air pg's thread > support/testing is at the moment. -sc As far as I know, thread support is on the ground for platforms that have tested it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
----- Original Message ----- From: "Sean Chittenden" <sean@chittenden.org> To: "Tom Lane" <tgl@sss.pgh.pa.us> Cc: "Andrew Dunstan" <andrew@dunslane.net>; <pgsql-hackers@postgresql.org> Sent: Tuesday, October 28, 2003 7:59 PM Subject: Re: [HACKERS] pg_ctl reports succes when start fails > > > We can also try to come up with a better scheme for verifying that > > > we have started properly - I will think about that. > > > > There have been previous suggestions for a "pg_ping" functionality, > > in which you could simply send a packet to the postmaster and it > > would answer back if it's open for business. You can approximate > > this by sending a deliberately invalid login packet, but it's not > > quite the same thing. I think there were some concerns about > > security though; check the archives. > > Um, I wrote pg_ping and sent it to -patches but got no comments. > > http://archives.postgresql.org/pgsql-patches/2003-07/msg00053.php > > pg_ping is actually the basis for the threaded benchmark program I've > got sitting in my tree, but I don't think folks here would look kindly > on a -lpthread dependency given how up in the air pg's thread > support/testing is at the moment. -sc > At least those parts of that patch that alter pg_ctl seem to be moot given that we are moving to a C version of pg_ctl (Joshua Drake tells me that CommandPrompt is willing to do that work). cheers andrew