Re: [BUGS] BUG #7738: Installer takes hours running icacls
This was reported in #7628 and was fixed in initcluster.vbs. Please send the installation logs (install-postgresql) from your system temp. On Fri, Dec 7, 2012 at 5:12 PM, wrote: > The following bug has been logged on the website: > > Bug reference: 7738 > Logged by: dnd > Email address: dnd1...@gmail.com > PostgreSQL version: 9.2.2 > Operating system: Windows 8 > Description: > > The installer is trying to change access permissions on every directory in > the drive where i've put the data directory, which is not the system drive. > > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > -- Sandeep Thakkar Senior Software Engineer EnterpriseDB Corporation The Enterprise Postgres Company Phone: +91.20.30589514 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message.
Re: [BUGS] BUG #7740: Installation cannot fine msi file
Hi Sandeep Note that this report is regarding an MSI installer, not one of the EDB ones. I suspect the problem is related to the fact that pgFoundry has had numerous problems over the last week or two, as well as the fact that the admins are in the process of upgrading GForge and splitting into two servers. That's broken a few things recently (which have been fixed pretty quickly once noticed). On Mon, Dec 10, 2012 at 6:01 AM, Sandeep Thakkar wrote: > Hi > > Do you see this on Win7 32bit or 64bit? Can you please send the installation > logs from your temp folder? > > > On Sat, Dec 8, 2012 at 4:35 AM, wrote: >> >> The following bug has been logged on the website: >> >> Bug reference: 7740 >> Logged by: Al Chirico >> Email address: al_chir...@hotmail.com >> PostgreSQL version: 9.2.2 >> Operating system: Win 7 Pro >> Description: >> >> I am getting the following Stack Builder error message during >> installation: >> >> "Failed to open >> >> http://ftp.postgresql.org/pub/projects/pgFoundry/stackbuilder/PgOleDB-1.0.0.20.msi"; >> >> >> >> -- >> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-bugs > > > > > -- > Sandeep Thakkar > Senior Software Engineer > EnterpriseDB Corporation > The Enterprise Postgres Company > Phone: +91.20.30589514 > > Website: www.enterprisedb.com > EnterpriseDB Blog: http://blogs.enterprisedb.com/ > Follow us on Twitter: http://www.twitter.com/enterprisedb > > This e-mail message (and any attachment) is intended for the use of the > individual or entity to whom it is addressed. This message contains > information from EnterpriseDB Corporation that may be privileged, > confidential, or exempt from disclosure under applicable law. If you are not > the intended recipient or authorized to receive this for the intended > recipient, any use, dissemination, distribution, retention, archiving, or > copying of this communication is strictly prohibited. If you have received > this e-mail in error, please notify the sender immediately by reply e-mail > and delete this message. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #7734: JPA2/Hibernate4 PG enum insert causes exception
On 05-12-2012 18:54, rmitch...@bzzagent.com wrote:
[This is not a PostgreSQL bug. It seems a limitation/bug in Hibernate dialect.]
> insert into my_table (gender) values ('male');
> insert into my_table (gender) values ('female');
> insert into my_table (gender) values ('unknown');
>
s/gender/gender_type/
> Caused by: org.postgresql.util.PSQLException: ERROR: column “gender_type” is
> of type GENDER_ENUM but expression is of type character varying
> Hint: You will need to rewrite or cast the expression.
>
What is the SQL generated by Hibernate? It seems it is casting the expression
to varchar like:
insert into my_table (gender_type) values ('male'::varchar);
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
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 #7750: pid file conflict in RedHat
The following bug has been logged on the website:
Bug reference: 7750
Logged by: Timothy J Bruce
Email address: postg...@tbruce.com
PostgreSQL version: 9.1.6
Operating system: RedHat v6.2
Description:
In line 238 of the rpm based init.d script, the pid file is called
specifically with a qualified path ("status -p
/var/run/postmaster-9.1.pid"), even though line 70 specifies a variable to
point to the pid file (pidfile="/var/run/postmaster-9.1.pid").
This is with rpm version of postgres 9.1.4 and 9.1.6 (we haven't tested
9.1.7 at this time).
--
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] init_htab causes SIGFPE (or worse) due to miscalculation for large nbuckets
On Sun, 2012-12-09 at 17:45 -0500, Tom Lane wrote: > Yeah. After looking at other uses of my_log2, it seems like > hash_estimate_size and hash_select_dirsize probably should also > bound their inputs to avoid overflow of 1 << my_log2() calculations. > > Alternatively, maybe we should hack my_log2 to do that bounding. > As-is, it seems like trouble waiting to happen. This won't protect > init_htab, which needs the shift result to fit in int not long. > But my_log2 is just plain broken for inputs larger than LONG_MAX/2, > anyway. It looks like all of the callers, except two, immediately shift the result. So perhaps it would be better to make a new function (something like "ceil_pow2") that returns the lowest power of two greater than or equal to the input, and it can return a long (bounded to +LONG_MAX). Then, the caller can bound the result further if needed, which should be less error-prone, because the caller would see that it returns a long (and compiler, but I don't seem to get a warning for implicit long->int conversions). Both of the callers that actually want a log2 already assume that the input is a power of two, so we can redefine my_log2 to require it. Regards, Jeff Davis -- 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] init_htab causes SIGFPE (or worse) due to miscalculation for large nbuckets
Jeff Davis writes: > On Sun, 2012-12-09 at 17:45 -0500, Tom Lane wrote: >> Alternatively, maybe we should hack my_log2 to do that bounding. >> As-is, it seems like trouble waiting to happen. This won't protect >> init_htab, which needs the shift result to fit in int not long. >> But my_log2 is just plain broken for inputs larger than LONG_MAX/2, >> anyway. > It looks like all of the callers, except two, immediately shift the > result. So perhaps it would be better to make a new function (something > like "ceil_pow2") that returns the lowest power of two greater than or > equal to the input, and it can return a long (bounded to +LONG_MAX). > Then, the caller can bound the result further if needed, which should be > less error-prone, because the caller would see that it returns a long > (and compiler, but I don't seem to get a warning for implicit long->int > conversions). > Both of the callers that actually want a log2 already assume that the > input is a power of two, so we can redefine my_log2 to require it. It seems reasonably possible that add-on code is using my_log2, so I'm hesitant to change the function's signature, or to change its behavior more than minimally necessary --- especially in the back branches. 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
Re: [BUGS] init_htab causes SIGFPE (or worse) due to miscalculation for large nbuckets
Jeff Davis writes:
> It looks like all of the callers, except two, immediately shift the
> result. So perhaps it would be better to make a new function (something
> like "ceil_pow2") that returns the lowest power of two greater than or
> equal to the input, and it can return a long (bounded to +LONG_MAX).
That does seem like a good idea. We need one for an int-sized result
too, to fix the original problem in init_htab. So I propose these
functions:
/* calculate ceil(log base 2) of num */
int
my_log2(long num)
{
int i;
longlimit;
/* guard against too-large input, which would put us into infinite loop
*/
if (num > LONG_MAX / 2)
num = LONG_MAX / 2;
for (i = 0, limit = 1; limit < num; i++, limit <<= 1)
;
return i;
}
/* calculate first power of 2 >= num, bounded to what will fit in a long */
long
next_power_of_two_long(long num)
{
/* my_log2's internal range check is sufficient */
return 1L << my_log2(num);
}
/* calculate first power of 2 >= num, bounded to what will fit in an int */
int
next_power_of_two_int(long num)
{
if (num > INT_MAX / 2)
num = INT_MAX / 2;
return 1 << my_log2(num);
}
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
Re: [BUGS] init_htab causes SIGFPE (or worse) due to miscalculation for large nbuckets
On Mon, 2012-12-10 at 20:27 -0500, Tom Lane wrote: > Jeff Davis writes: > > It looks like all of the callers, except two, immediately shift the > > result. So perhaps it would be better to make a new function (something > > like "ceil_pow2") that returns the lowest power of two greater than or > > equal to the input, and it can return a long (bounded to +LONG_MAX). > > That does seem like a good idea. We need one for an int-sized result > too, to fix the original problem in init_htab. So I propose these > functions: Looks good to me. One other corner case in the version of the patch I was working on was that nbuckets is compared to num_partitions, which is a long. We can assert that it is less than or equal to INT_MAX in hash_create. Aside from that, I'll drop my version of the patch, which doesn't have any useful differences from yours. Regards, Jeff Davis -- 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] init_htab causes SIGFPE (or worse) due to miscalculation for large nbuckets
Jeff Davis writes: > On Mon, 2012-12-10 at 20:27 -0500, Tom Lane wrote: >> That does seem like a good idea. We need one for an int-sized result >> too, to fix the original problem in init_htab. So I propose these >> functions: > Looks good to me. One other corner case in the version of the patch I > was working on was that nbuckets is compared to num_partitions, which is > a long. We can assert that it is less than or equal to INT_MAX in > hash_create. > Aside from that, I'll drop my version of the patch, which doesn't have > any useful differences from yours. I hadn't gone any further than to code and test the functions I listed. If you are working on a complete patch, please press on. 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
Re: [BUGS] init_htab causes SIGFPE (or worse) due to miscalculation for large nbuckets
On Mon, 2012-12-10 at 21:19 -0500, Tom Lane wrote: > I hadn't gone any further than to code and test the functions I listed. > If you are working on a complete patch, please press on. Attached. This fixes my test case[1] and uses the functions that you wrote. I made them static because I couldn't think of a reason for something outside to call them. Regards, Jeff Davis [1]: The test case will just eat a lot of memory right now, but that's only because I set work_mem so high. So, it doesn't actually complete, but it no longer corrupts the HASHHDR. htab.patch.gz Description: GNU Zip compressed data -- 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 #7744: docs should link to postgresql_psycopg2
The following bug has been logged on the website: Bug reference: 7744 Logged by: Chris Jerdonek Email address: chris.jerdo...@gmail.com PostgreSQL version: 9.2.2 Operating system: Mac OS X Description: This section of the docs: https://docs.djangoproject.com/en/1.4/topics/install/#get-your-database-running should provide the official link to postgresql_psycopg2. -- 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 #7743: pgAdmin III does not list default privileges for schemas
The following bug has been logged on the website: Bug reference: 7743 Logged by: Nathan Alden, Sr. Email address: m...@nathanalden.com PostgreSQL version: 9.2.2 Operating system: Windows 7 x64 Description: Follow these steps to reproduce: 1. Connect to the postgres DB. 2. Run the following SQL: create database test_database; 3. Run the following SQL: create role my_group; 4. Connect to the test_database DB. 5. Run the following SQL: alter default privileges in schema public grant all on types to my_group; 6. Open pgAdmin III. 7. Navigate to the public schema in test_database. 8. Right-click the public schema and choose Properties. 9. Select the Default Privileges tab. 10. Note that all four subtabs are empty, and the Role drop-down lists do not list my_group as a role. -- 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 #7746: Unable to install
The following bug has been logged on the website: Bug reference: 7746 Logged by: sumit kumar Email address: sumit4mys...@gmail.com PostgreSQL version: 9.2.2 Operating system: windows 8 Description: I have downloaded 9.2 version but I am unable to install postgreql in windows 8 please fix it as soon as possible. -- 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 #7742: Bug when backing up databases with default privileges defined on public schema
The following bug has been logged on the website: Bug reference: 7742 Logged by: Nathan Alden, Sr. Email address: m...@nathanalden.com PostgreSQL version: 9.2.2 Operating system: Windows 7 x64 Description: This report is more specific than my previous report, bug #7741. Feel free to delete the old one. Follow these steps to reproduce: 1. Connect to the postgres DB. 2. Run the following SQL: create database test_database; 3. Run the following SQL: create role my_group; 4. Connect to the test_database DB. 5. Run the following SQL: alter default privileges in schema public grant all on types to my_group; 6. Perform a pg_dump (database backup) and observe the following error: pg_dump: unknown object type (84) in default privileges -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Regarding Postgresql is not working in windows8 environment ..!
Dear Postgresql Team, I have downloaded 9.2 version but I am unable to install postgres sql in windows 8 please fix it as soon as possible. -- Thanks and Regards, Sumit Kumar Sharma
