Uninformative messages from pg_ctl

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/

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

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

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/

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

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

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/