Обсуждение: Why is failure to find file a "NOTICE"?

When I start the postmaster with PGDATA a relative path[*], then I
reproducably get things like this:

DEBUG:  Data Base System is in production state at Thu Nov  2 20:28:26 2000
NOTICE:  Cannot create init file pg-install/var/data/base/1/pg_internal.init.10037: No such file or directory
Continuinganyway, but there's something wrong.
 
NOTICE:  mdopen: couldn't open pg-install/var/data/global/1269: No such file or directory
NOTICE:  mdopen: couldn't open pg-install/var/data/global/1264: No such file or directory
NOTICE:  mdopen: couldn't open pg-install/var/data/global/1269: No such file or directory
FATAL 1:  cannot open relation pg_log
NOTICE:  Cannot create init file pg-install/var/data/base/1/pg_internal.init.10053: No such file or directory
Continuinganyway, but there's something wrong.
 
NOTICE:  mdopen: couldn't open pg-install/var/data/global/1269: No such file or directory
NOTICE:  mdopen: couldn't open pg-install/var/data/global/1264: No such file or directory

(hangs here, and then after a while)

FATAL: s_lock(40017029) at spin.c:131, stuck spinlock. Aborting.
FATAL: s_lock(40017029) at spin.c:131, stuck spinlock. Aborting.
Server process (pid 10053) exited with status 6 at Thu Nov  2 20:29:54 2000
Terminating any active server processes...
Server processes were terminated at Thu Nov  2 20:29:54 2000
Reinitializing shared memory and semaphores

It seems to me that "Continuing anyway, but there's something wrong." is a
rather inappropriate error handling, and this whole things seems pretty
scary for a trivial user mistake.


[*] -- The postmaster should refuse to start when the data directory is
not an absolute path.  I'm on that.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:
> DEBUG:  Data Base System is in production state at Thu Nov  2 20:28:26 2000
> NOTICE:  Cannot create init file pg-install/var/data/base/1/pg_internal.init.10037: No such file or directory
>         Continuing anyway, but there's something wrong.
> NOTICE:  mdopen: couldn't open pg-install/var/data/global/1269: No such file or directory

> It seems to me that "Continuing anyway, but there's something wrong." is a
> rather inappropriate error handling, and this whole things seems pretty
> scary for a trivial user mistake.

For pg_internal.init, which is inessential (it's merely a cache of index
info that can be extracted the hard way), I think the behavior is
reasonable.

I think the fact that mdopen doesn't treat open failure as a hard error
is an artifact of the way we currently handle relation deletion (ie,
physical file goes away before end of xact, hence relation descriptor
still exists and might get referenced).  I will try to clean this
up when I revise DROP TABLE to postpone deletion.

> [*] -- The postmaster should refuse to start when the data directory is
> not an absolute path.  I'm on that.

Either that, or convert it to an absolute path.  The problem is that the
backends chdir() to their individual databases' data directories, so
relative paths that were OK from the postmaster's perspective are no
good anymore.
        regards, tom lane

Tom Lane writes:

> > [*] -- The postmaster should refuse to start when the data directory is
> > not an absolute path.  I'm on that.
> 
> Either that, or convert it to an absolute path.  The problem is that the
> backends chdir() to their individual databases' data directories, so
> relative paths that were OK from the postmaster's perspective are no
> good anymore.

Is there a profound reason for this chdir()?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Either that, or convert it to an absolute path.  The problem is that the
>> backends chdir() to their individual databases' data directories, so
>> relative paths that were OK from the postmaster's perspective are no
>> good anymore.

> Is there a profound reason for this chdir()?

I like it because it keeps coredump files separate for backends in
different databases, not to mention separate from the postmaster's
own corefile.

It used to be true that some places in the backend would use relative
paths (ie, just "foo") to access some files, so that was also forcing
the working directory to be the same as the database subdirectory.
Other places build absolute paths (or what they think are absolute
paths, anyway) by prepending the -D string.  I'm not sure if all the
uses of relative paths have been removed or not.  Just on performance
grounds it seems to me that using relative paths is preferable, and we
ought to be removing the prepending of the -D path rather than making
it essential...
        regards, tom lane