Re: Why is failure to find file a "NOTICE"? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Why is failure to find file a "NOTICE"?
Date
Msg-id 26844.973199154@sss.pgh.pa.us
Whole thread Raw
In response to Why is failure to find file a "NOTICE"?  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Why is failure to find file a "NOTICE"?  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Next
From: Peter Eisentraut
Date:
Subject: Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)