8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED
in [PgSql]
|
From: Magnus Hagander on 23 Sep 2008 17:18 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 13 Oct 2008 17:38 Magnus Hagander wrote: >> 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. > > > I am getting this error on XP Pro. The buildfarm members run happily from the scheduler, but when run by hand from the command line they fail. This is true of both MinGW and MSVC. This is in *URGENT* need of a fix. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Dave Page" on 14 Oct 2008 03:37 On Mon, Oct 13, 2008 at 10:38 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > > > I am getting this error on XP Pro. The buildfarm members run happily from > the scheduler, but when run by hand from the command line they fail. This is > true of both MinGW and MSVC. > It's on my list to discuss it with Magnus when we meet in Italy tomorrow. The simple fix is to back out the change that broke it, which leaves us in our previous broken-but-less-severely state (which is what we did for the binary packages). > This is in *URGENT* need of a fix. I can't see us pushing a point release for this alone (I think I've seen two reports of people running into the problem when building from source themselves, and one was internal here in EDB), so the urgency is simply to ensure it's fixed before we do produce our next release imho. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Dave Page" on 14 Oct 2008 04:49 On Tue, Oct 14, 2008 at 9:43 AM, Charlie Savage <cfis(a)savagexi.com> wrote: >> It's on my list to discuss it with Magnus when we meet in Italy >> tomorrow. The simple fix is to back out the change that broke it, >> which leaves us in our previous broken-but-less-severely state (which >> is what we did for the binary packages). > > If you mean reverting the patch that Mangus mentioned, I tried that, and it > did not solve the problem. See: > > http://archives.postgresql.org/pgsql-hackers/2008-09/msg01517.php > > So I'm guessing it is something else. You must be seeing an unrelated issue then - it's definitely that change which caused us to start using the global namespace again, for which it seems additional privileges may be required, and reverting that change has fixed the issue on every failure machine I've seen. It's also worth noting that that was the *only* change made to the binary packages, and despite thousands of downloads we've seen no bug reports that could be attributed to this. >>> This is in *URGENT* need of a fix. >> >> I can't see us pushing a point release for this alone (I think I've >> seen two reports of people running into the problem when building from >> source themselves, and one was internal here in EDB), so the urgency >> is simply to ensure it's fixed before we do produce our next release >> imho. > > Well - building your own Postgres 8.3 on Windows using MingW appears broken. > Not sure how many people fall into that category, but its seems like a > fairly major issue. Very few people build their own Postgres on Windows, because it's not exactly straightforward to do because of all the dependencies. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 14 Oct 2008 09:33
Dave Page wrote: >> >> Well - building your own Postgres 8.3 on Windows using MingW appears broken. >> Not sure how many people fall into that category, but its seems like a >> fairly major issue. >> > > Very few people build their own Postgres on Windows, because it's not > exactly straightforward to do because of all the dependencies. > > IMNSHO, it is not acceptable to leave CVS for any significant period in a state where someone can't run "make check" by hand, and you certainly can't assume that no-one will want to do so. I can confirm that commenting out '+ 18' from the last loop of the offending patch allows me to run and test on XP-Pro. What do we actually need to create this object in the global namespace? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |