Обсуждение: Version 8.2.5 for Windows doesn't startup normally after upgrading from 8.2.4

Hello,

I just upgraded from 8.2.4 to 8.2.5 on Windows but the service doesn't
startup normally.
This is the first time I have trouble with an upgrade of version 8.2.
I have the following non standard configuration:
 - Program directory: C:\Archivos de programa\PostgreSQL\8.2\bin
 - Data Directory: D:\PostgreSQL\data
 - SSL ON
 - Working database is IOP_IPR (there is no POSTGRES database)
---------
When using
    pg_ctl start -D D:\PostgreSQL\data\
The server comes up normally, 2 messages appear:
    LOG:  could not load root certificate file "root.crt": No such
file or directory
    DETAIL:  Will not verify client certificates.
The log file contains only:
2007-09-18 14:36:25    LOG:  database system was shut down at 2007-09-18
14:33:27
2007-09-18 14:36:25    LOG:  checkpoint record is at 29/D1D4100
2007-09-18 14:36:25    LOG:  redo record is at 29/D1D4100; undo record
is at 0/0; shutdown TRUE
2007-09-18 14:36:25    LOG:  next transaction ID: 0/326345; next OID:
42275
2007-09-18 14:36:25    LOG:  next MultiXactId: 1; next MultiXactOffset:
0
2007-09-18 14:36:25    LOG:  database system is ready

---------
When started as a service with the following value of
pgsql-8.2\ImagePath in the registry:
    "C:\Archivos de programa\PostgreSQL\8.2\bin\pg_ctl.exe"
runservice -w -N "pgsql-8.2" -D "D:\PostgreSQL\data\"

The log file contains:
2007-09-18 14:28:34    LOG:  database system was shut down at 2007-09-18
14:26:02
2007-09-18 14:28:34    LOG:  checkpoint record is at 29/D1D4060
2007-09-18 14:28:34    LOG:  redo record is at 29/D1D4060; undo record
is at 0/0; shutdown TRUE
2007-09-18 14:28:34    LOG:  next transaction ID: 0/326343; next OID:
42275
2007-09-18 14:28:34    LOG:  next MultiXactId: 1; next MultiXactOffset:
0
2007-09-18 14:28:34    LOG:  could not load root certificate file
"root.crt": No such file or directory
2007-09-18 14:28:34    DETAIL:  Will not verify client certificates.
2007-09-18 14:28:34    LOG:  database system is ready
2007-09-18 14:28:35 127.0.0.1 postgres postgres FATAL:  the database
system is starting up

And then an endless list of
2007-09-18 14:28:35    LOG:  could not load root certificate file
"root.crt": No such file or directory
2007-09-18 14:28:35    DETAIL:  Will not verify client certificates.
2007-09-18 14:28:35 127.0.0.1 postgres postgres FATAL:  database
"postgres" does not exist
2007-09-18 14:28:36    LOG:  could not load root certificate file
"root.crt": No such file or directory
2007-09-18 14:28:36    DETAIL:  Will not verify client certificates.
2007-09-18 14:28:36 127.0.0.1 postgres postgres FATAL:  database
"postgres" does not exist

And I have to abort the startup.

Maybe the next is a hint:
When I had blocked the access to localhost with SSL=ON (using hostnossl
pg_hba.conf) there was a constant complaint (2 times per second) with:
127.0.0.1 postgres postgres FATAL:  no pg_hba.conf entry for host
"127.0.0.1", user "postgres", database "postgres", SSL on

---------
Have I something wrong with the configuration of the service?

Thanks on forehand.

--------------
Walter Roeland

On Tue, 2007-09-18 at 14:58 -0500, Walter Roeland wrote:
> 2007-09-18 14:28:36 127.0.0.1 postgres postgres FATAL:  database
> "postgres" does not exist
>
> And I have to abort the startup.
>
> Maybe the next is a hint:
> When I had blocked the access to localhost with SSL=ON (using hostnossl
> pg_hba.conf) there was a constant complaint (2 times per second) with:
> 127.0.0.1 postgres postgres FATAL:  no pg_hba.conf entry for host
> "127.0.0.1", user "postgres", database "postgres", SSL on
>
> ---------
> Have I something wrong with the configuration of the service?

Prior to 8.2.5, the -w option for pg_ctl was broken which meant that the
server would report itself running to the service control manager when
in actual fact it was still starting up. This would mean that dependent
services such as Slony or pgAgent would fail to start because the server
wasn't necessarily accepting connections at that time.

The -w option tells pg_ctl to attempt to connect to the server every few
seconds until successful - and only then report running status to the
service control manager, which will then attempt to start the dependent
services.

In your case, it seems like the 'postgres' database has been removed
which prevents pg_ctl connecting. When you blocked access through
pg_hba.conf, the fact that the database didn't exist was masked by the
lack of access to even attempt the connection.

To fix this, either:

- Modify the registry key (having taken a backup first of course) with
the pg_ctl command line, removing the -w option.

- Recreate the postgres database, and ensure it's accessible.

Regards, Dave.