From: Magnus Hagander on 14 Oct 2008 11:20 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 14 Oct 2008 11:42 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 14 Oct 2008 12:12 >> 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 14 Oct 2008 12:13 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 12 Nov 2008 01:20 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 |