On 14 July 2012 05:56, Craig Ringer <ring...@ringerc.id.au> wrote: > 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. >
Sorry for the misunderstanding. When I said that I reproduced the error in 9.1 version, I mean that I created the PGDATA with 9.1 postgresql server as 'local system' user and after that I tried to start the postgresql server as 'pss-svc' user and I took the error message which I sent with my previous mail. So there isn't any incompatibility problem with PGDATA. > 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? > There isn't any antivirus software on my computer. >> 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? As 'pss-svc' user I can open, read and write to the pg_control file ( I took backup of this file first ). I have exactly the same problem when I try to start progresql server as Administrator instead of 'pss-svc' user > > 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs