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

From Vladimir Sitnikov
Subject Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED
Date
Msg-id 1d709ecc0810140223h39601e6bx2967286c7cdc5d6f@mail.gmail.com
Whole thread Raw
In response to Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED  (Charlie Savage <cfis@savagexi.com>)
List pgsql-hackers
On Tue, Oct 14, 2008 at 12:43 PM, Charlie Savage <cfis@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.

I confirm that fix (actually a rollback of 4 changes) solves "access_denied" issue in Vista+MinGW+latest snapshot of 8.4

As Microsoft says, only services are allowed (as they are the only processes run in session0) to created objects in "Global\" namespace.

The only workaround to create globally accessible objects I saw was to create shared memory locally, specify the correct non-null DACL (say, allow access for owner) and access that created shared memory using "\Session\[SID]\shared_memory_name" name. The only problem is to figure out the session identifier where shared memory was created.
I do not see an elegant solution here. It looks quite easy to store the SID into some file in working directory, then read it and connect to the shared memory.

If that makes sense, I could implement it that way and test it under Vista.

Sincerely yours,
Vladimir Sitnikov

pgsql-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED
Next
From: KaiGai Kohei
Date:
Subject: Updates of SE-PostgreSQL 8.4devel patches (r1120)