[Please keep the mailing list CC'd] On Mon, Oct 11, 2010 at 8:40 PM, <johannes.meid...@rohde-schwarz.com> wrote: > >> On Mon, Oct 11, 2010 at 2:23 AM, Craig Ringer >> <cr...@postnewspapers.com.au> wrote: >> > On 10/08/2010 07:53 PM, Johannes Meidert wrote: >> >> >> >> The following bug has been logged online: >> >> >> >> Bug reference: 5699 >> >> Logged by: Johannes Meidert >> >> Email address: johannes.meid...@rohde-schwarz.com >> >> PostgreSQL version: 9.0.1 >> >> Operating system: windows >> >> Description: Postgres runs only under default user. >> >> Details: >> >> >> >> If a --superaccount is specified during installation other than >> >> 'postgres', >> >> the service will not start correctly and there are lots of errors "role >> >> <postgres> does not exist" in the DB error log. >> >> The option -- superaccount should be removed. >> > >> > It does seem a bit odd - if the super account is wired into the database >> > cluster at initdb time, you'd think it'd be read from there on startup. >> > >> > Comments, anybody? This report hasn't seen a response, but seems to have >> > some legitimacy as a usability issue if not an outright bug. >> >> I saw an email from our QA team a few minutes ago saying they have >> been unable to reproduce the problem. What command line/options file >> did you use exactly Johannes? > > The installation doesn't seem to be the problem. After installing we replace > the > pg_hba.conf with another one with 'trust' authentication: > > # IPv4 local connections: > host all all 127.0.0.1/32 trust > # IPv4 all addresses. jm 2010 > host all all 0.0.0.0/0 trust > # IPv6 local connections: > #host all all ::1/128 trust > > After that when starting the service there is an error message that the > service > didn't start 8though it is running) and we get the "role <postgres> does not > exist" > error messages. > The error disappers if we change back to "MD5" or if we use user "postgres" > when installing. > > Probably for production systems it isn't a good idea anyway to use 'trust', > so we will change. > > Installation: > > set PGDATA=c:\_DB > > rem is using trust authentication, do not give a password. "trust" is set > using the pg_hba.conf file > postgresql-9.0.1-1-windows --mode unattended --unattendedmodeui minimal > --installer-language en --serviceaccount postgres --servicepassword > system$01 --serverport 65432 --superaccount allaudio --servicename AudioDB > --datadir %PGDATA% > > rem copy Config - files for remote - access > copy *.conf %PGDATA%\ /y > > rem create DB. > "%ProgramFiles%\PostgreSQL\9.0\bin\createdb" -e -p 65432 -h 127.0.0.1 -U > allaudio AllAudio > >
I have a suspicion that the problem is that because your serviceaccount is "postgres", pg_ctl tries to connect to the server as "postgres" to test that it's up (the -w option). We've seen similar problems in the past because the database name postgres is hardcoded into pg_ctl. [Get-out-of-jail card: having taken a suitable backup of your system], can you edit the service command line in the registry and see if startup then succeeds? You should find it in the key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AudioDB\ImagePath -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
