Обсуждение: could not open file "global/pg_database"

Dear PostgreSQL users,

I'm running postgreSQL 8.1 (installed with YaST) on a Suse 10.2 machine.
My $PGDATA variable is /home/postgres/data

When I initiate the databases with initdb without argument. It seems to works
as I get this :
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale en_US.UTF-8.
The default database encoding has accordingly been set to UTF8.

fixing permissions on existing directory /home/postgres/data ... ok
creating directory /home/postgres/data/global ... ok
creating directory /home/postgres/data/pg_xlog ... ok
creating directory /home/postgres/data/pg_xlog/archive_status ... ok
creating directory /home/postgres/data/pg_clog ... ok
creating directory /home/postgres/data/pg_subtrans ... ok
creating directory /home/postgres/data/pg_twophase ... ok
creating directory /home/postgres/data/pg_multixact/members ... ok
creating directory /home/postgres/data/pg_multixact/offsets ... ok
creating directory /home/postgres/data/base ... ok
creating directory /home/postgres/data/base/1 ... ok
creating directory /home/postgres/data/pg_tblspc ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 1000
creating configuration files ... ok
creating template1 database in /home/postgres/data/base/1 ... ok
initializing pg_authid ... ok
enabling unlimited row size for system tables ... ok
initializing dependencies ... ok
creating system views ... ok
loading pg_description ... ok
creating conversions ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the -A option the
next time you run initdb.

Success. You can now start the database server using:

    postmaster -D /home/postgres/data
or
    pg_ctl -D /home/postgres/data -l logfile start

But it I try to run the daemon with

pg_ctl -D /home/postgres/data -l logfile start, I get this :
Postmaster running (and that's all, nothing is added in logfile) ... and the
server does not seem to work.

If I try create a database

createdb testdb

createdb: could not connect to database postgres: FATAL:  could not open
file "global/pg_database": No such file or directory

If I try to create a user

createuser sylvain
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
createuser: could not connect to database postgres: FATAL:  could not open
file "global/pg_database": No such file or directory

It seems that the server cannot get access to global/pg_database but why? Even
if all the of this file (777) are available. It cannot get access to it?

Does somebody as any idea?

Thanks a lot,

Sylvain

Sylvain Brohee <sbrohee@ulb.ac.be> writes:
> When I initiate the databases with initdb without argument. It seems to works
> ...
> But it I try to run the daemon with

> pg_ctl -D /home/postgres/data -l logfile start, I get this :
> Postmaster running (and that's all, nothing is added in logfile) ... and the
> server does not seem to work.

Hmm ... "postmaster starting" is all that you should see from pg_ctl,
but the lack of anything in the logfile is very suspicious.  Try it
with -w to see if pg_ctl reports the postmaster really does start.

> It seems that the server cannot get access to global/pg_database but why? Even
> if all the of this file (777) are available. It cannot get access to it?

"No such file or directory" is not a permissions problem.  What I
suspect is that your new postmaster didn't start, and the reason is
that there's still an old postmaster hanging around and monopolizing
the port number, and that you've managed to cut that old postmaster
off at the knees by deleting its database directory tree out from
under it.  If so you need to find and kill the old postmaster (or
maybe a quick system reboot would be easiest).

Or it could be something even more mundane than that, like there's
no permission to write the logfile.  But in any case I bet you're
not talking to the same postmaster process you think you are.

            regards, tom lane