Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED
Date
Msg-id 48D95D2B.8040803@hagander.net
Whole thread Raw
In response to 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED  (Charlie Savage <cfis@savagexi.com>)
Responses Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED  (Charlie Savage <cfis@savagexi.com>)
Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Charlie Savage wrote:
> I'm trying to upgrade my copy of postgresql from 8.2.x to 8.3.4 on a
> Windows Vista SP1 laptop. I build postgres using mingw/msys and have had
> no issues with 8.1.x and 8.2.x.  However, with 8.3.4 I run into problems.
> 
> First, building fails:
> 
> c:/Development/MingW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/sspi.h:60:
> 
> error: syntax error before "SECURITY_STRING"
> In file included from
> c:/Development/MingW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/security.h:39,
> 
>                  from ../../../../src/include/libpq/libpq-be.h:50,
> 
> This also happens from libpq-int.h.  The solution in both cases is to
> add an additional header file:
> 
> #ifdef ENABLE_SSPI
> #define SECURITY_WIN32
> #include <ntsecapi.h>  <------- Add this include
> #include <security.h>
> #undef SECURITY_WIN32
> 
> That fixes the build issue.

What the... This works fine on the mingw versions on the buildfarm :-(

Have you done anything special to your mingw install?


> Second, once I've successfully built and installed postgres, I run into
> a bigger problem.  When using initdb, I get this error:
> 
> creating template1 database in c:/Data/postgres30/base/1 ... FATAL:
> could not create shared memory segment: 5
> DETAIL:  Failed system call was CreateFileMapping(size=1802240,
> name=Global\PostgreSQL:c:/Data/postgres).
> 
> A bit of googling and reading MSDN docs shows that applications that
> don't run in Session 0 on Vista are not allowed to create shared memory
> in the Global namespace.  Since initdb is invoked from the command line,
> it runs in Session 1.

Where did you find that information? I've been specifically looking for
it, but my searches didn't turn up anything conclusive.

The latest versions contain a fix for the global namespace code. Dave
noticed that this caused issues on vista and thus manually reverted the
patch in the official binary installer. But since we haven't (hadn't)
yet found documentation as to *why* it was failing, the patch has not
yet been reverted in the main source tree.

This is why it's working, probably, and it's not related to how it's built.

If you want to revert the patch in your local tree, this is the one:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/port/win32_shmem.c?r1=1.4&r2=1.5

Specifically, you can reintroduce the old bug (that I think is hat made
it work on Vista) by removing the +18 in the lowest loop there.

//Magnus



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: pg_settings.sourcefile patch is a security breach
Next
From: Bruce Momjian
Date:
Subject: Re: 0x1A in control file on Windows