Re: Uninformative messages from pg_ctl
От | Simon Riggs |
---|---|
Тема | Re: Uninformative messages from pg_ctl |
Дата | |
Msg-id | 1191937431.4233.15.camel@ebony.site обсуждение исходный текст |
Ответ на | Re: Uninformative messages from pg_ctl (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: