Re: Why is failure to find file a "NOTICE"?

Peter Eisentraut <peter_e(at)gmx(dot)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