Thread: pg_ctl reports succes when start fails

pg_ctl reports succes when start fails

From
Tommi Maekitalo
Date:
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


Re: pg_ctl reports succes when start fails

From
Tom Lane
Date:
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


Re: pg_ctl reports succes when start fails

From
Andrew Dunstan
Date:
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





Re: pg_ctl reports succes when start fails

From
Christopher Kings-Lynne
Date:
> 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




Re: pg_ctl reports succes when start fails

From
Tom Lane
Date:
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


Re: pg_ctl reports succes when start fails

From
Christopher Kings-Lynne
Date:
> 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




Re: pg_ctl reports succes when start fails

From
Tom Lane
Date:
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


Re: pg_ctl reports succes when start fails

From
Christopher Kings-Lynne
Date:
>>The latter...why won't it affect the postmaster state?
> 
> 
> Because it's a *comment*.

Shouldn't it revert to the default value?

Chris




Re: pg_ctl reports succes when start fails

From
Bruce Momjian
Date:
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
 


Re: pg_ctl reports succes when start fails

From
Bruce Momjian
Date:
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

Re: pg_ctl reports succes when start fails

From
Andrew Dunstan
Date:
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




Re: pg_ctl reports succes when start fails

From
Peter Eisentraut
Date:
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



Re: pg_ctl reports succes when start fails

From
Andrew Dunstan
Date:
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


Re: Defaults for GUC variables (was Re: pg_ctl reports

From
Michael Brusser
Date:
> 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.




Re: pg_ctl reports succes when start fails

From
Tom Lane
Date:
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


Re: pg_ctl reports succes when start fails

From
Andrew Dunstan
Date:
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



Re: Defaults for GUC variables (was Re: pg_ctl reports

From
Christopher Kings-Lynne
Date:
> 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


Re: pg_ctl reports succes when start fails

From
Sean Chittenden
Date:
> > 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


Re: pg_ctl reports succes when start fails

From
Bruce Momjian
Date:
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
 


Re: pg_ctl reports succes when start fails

From
"Andrew Dunstan"
Date:
----- 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