Re: [BUGS] BUG #4785: Installation fails
Dave, Should the installer be the user "postgres"? I've installed both as "rik" (global domain) and "postgres" (local domain). Each time installation fails to write the "conf" file in /data. See below for answers to your questions. Thanks! Roger P.S. OS is XP -Original Message- From: Dave Page [mailto:dp...@pgadmin.org] Sent: Thursday, May 07, 2009 2:31 AM To: Krimstock, Roger I (Roger); Pg Bugs Subject: Re: [BUGS] BUG #4785: Installation fails [Please keep the list CC'd] On Thu, May 7, 2009 at 3:14 AM, Krimstock, Roger I (Roger) wrote: > > The command that seems to be failing appears to be: > > echo y|cacls "C:\Program Files\PostgreSQL\8.4\data" /T /G > "":F > > where is your current username as returned by a scripting object. Can you try running the command in a command prompt please, and see if it works interactively (using your username)? >>[RIK] for both users, "rik" and "postgres", the response is: "Access is denied" OK, so the basic question is, why can't you set permissions on that directory? The installer obviously thinks you have some admin privileges, otherwise it would have aborted at startup. Can you answer the following please and we can try to figure out the issue? - Is your computer on a domain? Yes - Is your user account a domain or local account? Domain account - Are you a local administrator, domain administrator or member of the power users group (or anything similar?) Local administrator and I added myself to power users. - Do you have permissions to write to each directory in the path C:\Program Files\PostgreSQL\8.4\data ? Yes - Is this an NTFS filesystem? Yes -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4785: Installation fails
On Tue, May 12, 2009 at 2:17 AM, Krimstock, Roger I (Roger) wrote: > > Dave, > Should the installer be the user "postgres"? I've installed both as > "rik" (global domain) and "postgres" (local domain). Each time > installation fails to write the "conf" file in /data. See below for > answers to your questions. No - the postgres user is created by the installer so you can't use it to run the installer on the first installation. It also doesn't have any administrative permissions which are required. > - Is your computer on a domain? > Yes > - Is your user account a domain or local account? > Domain account > - Are you a local administrator, domain administrator or member of the > power users group (or anything similar?) > Local administrator and I added myself to power users. > - Do you have permissions to write to each directory in the path > C:\Program Files\PostgreSQL\8.4\data ? > Yes > - Is this an NTFS filesystem? > Yes So you have permission to write to those directories, but cacls fails if you try to change the permissions on them. Weird. Magnus; any ideas on what could cause this? I must admit, my Windows management-fu is somewhat rusty these days. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4806: Bug with GiST index and empty integer array?
The following bug has been logged online: Bug reference: 4806 Logged by: Joerg Kiegeland Email address: kiegel...@ikv.de PostgreSQL version: PostgreSQL8.3.7 Operating system: Windows XP Description:Bug with GiST index and empty integer array? Details: The GiST index seems not to be able to find empty integer arrays. The bug can be easily reproduced on a simple test database: To create the table and the data execute: CREATE TABLE test_intarray_table ( id text NOT NULL PRIMARY KEY, intarray_column integer[] ); INSERT INTO test_intarray_table (id, intarray_column) VALUES ('x', '{}'); CREATE INDEX intarray_index ON test_intarray_table USING gist (intarray_column); To query the data execute: SET ENABLE_SEQSCAN TO OFF; --disable sequential scan, which is performed for small tables SELECT * FROM test_intarray_table WHERE "intarray_column" = '{}'; The result set of this query does not include the row with id x, though the condition should match! When deleting the index intarray_index, x is found! So we proposed our customer to simply delete the index. However it goes slower then. I would expect the GiST index to either report an error that empty array queries are not supported (like GIN index does) or otherwise to return the correct result, since the result of a query should be independent of an index usage. As we reduced this bug to this little example from a very large database and a much larger query (took hours for this "simplification"), we disabled the sequential scan, however in our large database we could reproduce this error without disabling the sequential scan. The bug also appears with PostgreSQL8.4 Beta and with PostgreSQL8.3.6. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4806: Bug with GiST index and empty integer array?
"Joerg Kiegeland" writes: > The GiST index seems not to be able to find empty integer arrays. Yeah, this is a known issue. We are looking into what can be done about it for 8.4. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs