Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why is failure to find file a "NOTICE"?
Date: 2000-11-02 21:05:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

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

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2000-11-02 21:19:06
Subject: Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README
Previous:From: Tom LaneDate: 2000-11-02 20:42:43
Subject: Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group