Обсуждение: Problem with starting Postgres

I am using PG 7.4 I was creating a new Databasecluster. after a first
successful start of  postmaster i wanted to stop and start again. pg_ctl
teminated with a message that posmaster won't stop, so i stopped it with -m
immediate. Since then it is not possible to start again. I see the
following:

2005-07-18 11:37:56 LOG:  database system shutdown was interrupted at
2005-07-18 11:32:00 CEST
2005-07-18 11:37:56 LOG:  checkpoint record is at 0/10
2005-07-18 11:37:56 LOG:  redo record is at 0/10; undo record is at 0/10;
shutdown TRUE
2005-07-18 11:37:56 LOG:  next transaction ID: 3; next OID: 16384
2005-07-18 11:37:56 LOG:  database system was not properly shut down;
automatic recovery in progress
postmaster successfully started
hn@mozart:/mnt/ha1/postgresql> 2005-07-18 11:37:56 LOG:  redo starts at 0/50
2005-07-18 11:37:56 LOG:  record with zero length at 0/74
2005-07-18 11:37:56 LOG:  redo done at 0/50

at this point the program stalls.

When i start pgsql i receive the followin message:
 FATAL:  the database system is starting up
psql: FATAL:  the database system is starting up

I have tried many things even deleted the whole database and tried to
recreate it but the result stays the same.
Has anyone any suggestions?

Thanks in advance
r.hnat

"Reinhard Hnat" <hnat@logotronic.co.at> writes:
> I am using PG 7.4 I was creating a new Databasecluster. after a first
> successful start of  postmaster i wanted to stop and start again. pg_ctl
> teminated with a message that posmaster won't stop, so i stopped it with -m
> immediate. Since then it is not possible to start again.

I think you probably have a process or two still hanging around.  Do
"ps auxww | grep postgres" (or local equivalent) and look for processes
that are/were children of the old postmaster or one of the subsequent
attempts.  Get rid of 'em with kill -9.

Once you are certain there are none left, "rm -rf" the database
directories and rerun initdb.

(Of course this'd be a lot harder if you were trying to preserve data,
but since there's nothing to preserve, you may as well take the brute
force approach.)

            regards, tom lane