On 07/14/2012 12:18 AM, Petros Tsialiamanis wrote:
> Thank you very much for your reply.
Thanks for coming back and re-testing with a modern PostgreSQL.
PostgreSQL 9.1 isn't compatible with databases from 8.3, so you can't
actually run Pg 9.1 directly against a datadir from 8.3; that's why I
suggested the latest 8.3 point release.
However, your startup should be failing with a message telling you this,
not with a permissions error then (more importantly) a crash.
Is there any antivirus software on this computer? If so, what is it?
Does excluding the PostgreSQL data directory, PostgreSQL executable
directory, and (if the AV supports it) adding process exclusions for
"postmaster.exe" and "postgres.exe" have any effect?
> The 'pss-svc' user is member of the administrators group and has full
> permissions for PostgreSQL data directory.
It clearly doesn't, because PostgreSQL is getting "permission denied"
from the OS when accessing global/pg_control. Maybe you need to apply
permissions recursively?
Remember that on Win7, membership of the Administrators group doesn't
grant the ability to perform file operations as administrator directly.
It grants the ability to create privileged processes that can then
perform those operations using implicit or explicit "run as
administrator" functionality.
I can't off the top of my head think of a safe way on Windows to test if
a file is writable as a given user without potentially changing its
contents. On Linux I'd say "run touch /path/name" but there's no touch
command on Windows. global\pg_control is a binary file so you can't just
open it and save it in notepad (DO NOT DO THIS) as it'll corrupt it
hopelessly, and Windows doesn't come with a binary-safe editor.
> I reproduced the crash with PostgreSQL version 9.1.4.12152 with the
> following output :
[snip]
> LOCATION: _dosmaperr, .\src\port\win32error.c:186
> PANIC: 42501: could not open control file "global/pg_control":
> Permission denied
> LOCATION: ReadControlFile, .\src\backend\access\transam\xlog.c:4687
>
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
> ******************************************************************
OK, that's not very nice behaviour - it should be doing a clean exit
after it fails to read global/pg_control . Hmm. I'm not sure off the top
of my head how to tackle tracking that down without a debugger. I don't
really have time at the moment to set up a test environment under
Windows and see if I can reproduce it.
Ideas anyone? Can someone with a Windows box use pg_ctl to try to start
a new Pg instance against a datadir with an unwritable pg_control ?
--
Craig Ringer
