Thread: Uninformative messages from pg_ctl

Uninformative messages from pg_ctl

From
Simon Riggs
Date:
These messages from pg_ctl are not useful

$ pg_ctl -D nonexistent stop
pg_ctl: PID file "nonexistent/postmaster.pid" does not exist
Is server running?

The message should say
pg_ctl: Data Directory "nonexistent" does not exist

$ pg_ctl -D nonexistent start
postgres cannot access the server configuration file
"/usr/local/pgsql/nonexistent/postgresql.conf": No such file or
directory
server starting

The message should say 
pg_ctl: Data Directory "nonexistent" does not exist

and should not say "server starting" at all.


Any objections to changing them?


--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



Re: Uninformative messages from pg_ctl

From
Peter Eisentraut
Date:
Am Dienstag, 9. Oktober 2007 schrieb Simon Riggs:
> These messages from pg_ctl are not useful
>
> $ pg_ctl -D nonexistent stop
> pg_ctl: PID file "nonexistent/postmaster.pid" does not exist
> Is server running?
>
> The message should say
> pg_ctl: Data Directory "nonexistent" does not exist

Well, this objection could apply to any place where a file is being opened.  
I'm curious how you plan to sort out the difference, considering that open() 
simply returns ENOENT in both cases.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Re: Uninformative messages from pg_ctl

From
Magnus Hagander
Date:
On Tue, Oct 09, 2007 at 01:09:19PM +0200, Peter Eisentraut wrote:
> Am Dienstag, 9. Oktober 2007 schrieb Simon Riggs:
> > These messages from pg_ctl are not useful
> >
> > $ pg_ctl -D nonexistent stop
> > pg_ctl: PID file "nonexistent/postmaster.pid" does not exist
> > Is server running?
> >
> > The message should say
> > pg_ctl: Data Directory "nonexistent" does not exist
> 
> Well, this objection could apply to any place where a file is being opened.  
> I'm curious how you plan to sort out the difference, considering that open() 
> simply returns ENOENT in both cases.

You'd do opendir() on the directory part fisrt, I assume.

A question I had about it is, where are we wrt translations? When do we
plan string freeze? 

//Magnus


Re: Uninformative messages from pg_ctl

From
Simon Riggs
Date:
On Tue, 2007-10-09 at 13:20 +0200, Magnus Hagander wrote:
> On Tue, Oct 09, 2007 at 01:09:19PM +0200, Peter Eisentraut wrote:
> > Am Dienstag, 9. Oktober 2007 schrieb Simon Riggs:
> > > These messages from pg_ctl are not useful
> > >
> > > $ pg_ctl -D nonexistent stop
> > > pg_ctl: PID file "nonexistent/postmaster.pid" does not exist
> > > Is server running?
> > >
> > > The message should say
> > > pg_ctl: Data Directory "nonexistent" does not exist
> > 
> > Well, this objection could apply to any place where a file is being opened.  
> > I'm curious how you plan to sort out the difference, considering that open() 
> > simply returns ENOENT in both cases.
> 
> You'd do opendir() on the directory part fisrt, I assume.

Yes, so we catch the real error.

> A question I had about it is, where are we wrt translations? When do we
> plan string freeze? 

Not one day after Beta1, I presume.

We would keep the "pid does not exist" error because it still might be
true that we have a data directory, but no pid file.

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



Re: Uninformative messages from pg_ctl

From
Peter Eisentraut
Date:
Am Dienstag, 9. Oktober 2007 schrieb Simon Riggs:
> On Tue, 2007-10-09 at 13:20 +0200, Magnus Hagander wrote:
> > On Tue, Oct 09, 2007 at 01:09:19PM +0200, Peter Eisentraut wrote:
> > > Well, this objection could apply to any place where a file is being
> > > opened. I'm curious how you plan to sort out the difference,
> > > considering that open() simply returns ENOENT in both cases.
> >
> > You'd do opendir() on the directory part fisrt, I assume.
>
> Yes, so we catch the real error.

Note that opendir() requires different permissions than reading or writing a 
file in that directory.  So you might in fact be catching the wrong error.  
stat() might work better, but I'm not sure.

You would also have to cope with the directory structure changing as you 
traverse it.

Also consider the effort required to slice apart directory names in a portable 
way and iterate and catch all these problems.  This could at best be used in 
a limited number of places where pilot errors are common.

I believe, however, that this approach is wrong.  The "real error", as you put 
it, is the one reported by the kernel -- by definition.  Everything else is 
at best a "hint".

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Re: Uninformative messages from pg_ctl

From
Simon Riggs
Date:
On Tue, 2007-10-09 at 14:25 +0200, Peter Eisentraut wrote:
> Am Dienstag, 9. Oktober 2007 schrieb Simon Riggs:
> > On Tue, 2007-10-09 at 13:20 +0200, Magnus Hagander wrote:
> > > On Tue, Oct 09, 2007 at 01:09:19PM +0200, Peter Eisentraut wrote:
> > > > Well, this objection could apply to any place where a file is being
> > > > opened. I'm curious how you plan to sort out the difference,
> > > > considering that open() simply returns ENOENT in both cases.
> > >
> > > You'd do opendir() on the directory part fisrt, I assume.
> >
> > Yes, so we catch the real error.
> 
> Note that opendir() requires different permissions than reading or writing a 
> file in that directory.  So you might in fact be catching the wrong error.  
> stat() might work better, but I'm not sure.

Yeh, I presumed he was speaking Windows

> You would also have to cope with the directory structure changing as you 
> traverse it.

No directory. pid file is in data directory root

We'll still fail with the old error if anything changes

> Also consider the effort required to slice apart directory names in a portable 
> way and iterate and catch all these problems.  This could at best be used in 
> a limited number of places where pilot errors are common.

Nothing to do. The -D option supplies the data dir name, we add the pid
file name on top, so no munging required.

> I believe, however, that this approach is wrong.  The "real error", as you put 
> it, is the one reported by the kernel -- by definition.  Everything else is 
> at best a "hint".
> 
--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



Re: Uninformative messages from pg_ctl

From
Simon Riggs
Date:
On Tue, 2007-10-09 at 14:25 +0200, Peter Eisentraut wrote:

> I believe, however, that this approach is wrong.  The "real error", as you put 
> it, is the one reported by the kernel -- by definition.  Everything else is 
> at best a "hint".

Are you objecting to making the wording of the hint/error clearer?

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



Re: Uninformative messages from pg_ctl

From
Peter Eisentraut
Date:
Am Dienstag, 9. Oktober 2007 schrieb Simon Riggs:
> On Tue, 2007-10-09 at 14:25 +0200, Peter Eisentraut wrote:
> > I believe, however, that this approach is wrong.  The "real error", as
> > you put it, is the one reported by the kernel -- by definition. 
> > Everything else is at best a "hint".
>
> Are you objecting to making the wording of the hint/error clearer?

Not at all.  I'm just trying to point out that it's not quite as obvious as it 
may seem.  Let's see a patch.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/