Re: 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(dot)maekitalo(at)epgmbh(dot)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(dot)maekitalo(at)epgmbh(dot)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(at)familyhealth(dot)com(dot)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(at)familyhealth(dot)com(dot)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(dot)maekitalo(at)epgmbh(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Tom Lane wrote:
> Tommi Maekitalo <t(dot)maekitalo(at)epgmbh(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)gmx(dot)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(at)familyhealth(dot)com(dot)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(at)familyhealth(dot)com(dot)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(at)dunslane(dot)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(at)dunslane(dot)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

On Mon, 27 Oct 2003 10:22:32 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

Servus
Manfred

> > 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

----- Original Message -----
From: "Sean Chittenden" <sean(at)chittenden(dot)org>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>; <pgsql-hackers(at)postgresql(dot)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