From: Magnus Hagander on
Tom Lane wrote:
> "Robert Haas" <robertmhaas(a)gmail.com> writes:
>>> The user running initdb (or the postmaster) needs
>>> SeCreateGlobalPrivilege - which is something we cannot really start
>>> telling people they must have. My view is that we revert the change
>>> (well, replace it with something that looks less like a broken attempt
>>> to use the global namespace) and leave it at that. iirc, the use of
>>> the global namespace is there to ensure things work as they should
>>> under a non-console terminal services session - which is pretty rare
>>> and can usually be avoided.
>
>> I'm not so sure that non-console terminal service sessions should be
>> categorized as "pretty rare".
>
> Would there be any value in trying a global name first and falling back
> to non-global if that fails?

Hmm. We could fail on the specific error that we get in this case,
perhaps. I think it should be "a required privilege is not held by the
client", which shouldn't occur otherwise. If it's just "access denied",
that could equally well be caused by a running postmaster in a different
session under a different useraccount...

//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: "Dave Page" on
On Tue, Oct 14, 2008 at 4:19 PM, Magnus Hagander <magnus(a)hagander.net> wrote:
>
> Not quite. The reason it's in the global namespace is to provide an
> interlock preventing the starting of a postmaster in two different
> sessions at the same time against the same data directory. We need to
> figure out exactly how much this interlock is reduced, and if there is
> something else we can do to make it work on Vista+...

This isn't a Vista+ issue - it happens on XP as well.


--
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: "Robert Haas" on
>> I'm not so sure that non-console terminal service sessions should be
>> categorized as "pretty rare".
>>
>> I use them routinely.
>
> For installing and running Postgres? Note that we're not talking about
> running clients apps here, but the server itself.

Sure, why not? I mean, I've come across applications that simply fail
to install - or run - from a non-console session, but it's pretty
broken. You'd at least like to get an error message that says, hey,
you have to run this from a console session, rather than just crapping
out for no obvious reason.

....Robert

--
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
On Tue, Oct 14, 2008 at 5:12 PM, Robert Haas <robertmhaas(a)gmail.com> wrote:
>>> I'm not so sure that non-console terminal service sessions should be
>>> categorized as "pretty rare".
>>>
>>> I use them routinely.
>>
>> For installing and running Postgres? Note that we're not talking about
>> running clients apps here, but the server itself.
>
> Sure, why not? I mean, I've come across applications that simply fail
> to install - or run - from a non-console session, but it's pretty
> broken. You'd at least like to get an error message that says, hey,
> you have to run this from a console session, rather than just crapping
> out for no obvious reason.

You do get such a message from the installer.

--
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: Charlie Savage on
Just wanted to close off this thread.

Previously I reported that building 8.3.4 with MingW on Windows resulted
in an initdb executable that couldn't create new databases due to
security restrictions in creating global file mappings in Vista.

I'm happy to say that the problem seems fixed in 8.3.5, which I have
successfully built, installed, and created new databases with.

And just to note this for anyone else who runs into the issue - if you
build postgresql with MingW then make sure you are using the latest
version of the MingW runtime:

http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=11598

Specifically, use version 3.15.1 released on 2008-10-04 (or hopefully
later). In the previous version, getopt_long is broken, meaning you
cannot use any long style switches to initdb (for example, initdb
--locale=C doesn't work and causes initdb to exit with an error message).

Thanks,

Charlie


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: "\ef <function>" in psql
Next: ERROR: incompatible library