Re: [BUGS] BUG #5015: MySQL migration wizard does not start

Ashesh, The update files worked. I unzipped the download into the EnterpriseDB-MigrationWizard replacing the existing jars in EnterpriseDB-MigrationWizard and the lib directory. The existing command did work so it was not a matter of backslashes vs. forward slashes. Thanks, KenS. From: Ashe

[BUGS] psql: FATAL: the database system is in recovery mode

Hi All, I am trying to run as follows queries -- SELECT PageIndex, (SUM(ConnectDoneTime - StartTime) * 100) / SUM(EndTime - StartTime) AS "ConnectTimePct", (SUM(WriteCompleTime - ConnectDoneTime) * 100) / SUM(EndTime - StartTime) AS "RequestSentTimePct", (SUM(FirstBy

Re: [BUGS] psql: FATAL: the database system is in recovery mode

Bhushan Verma wrote: > Hi All, > > I am trying to run as follows queries > -- > SELECT PageIndex, >(SUM(ConnectDoneTime - StartTime) * 100) / SUM(EndTime - StartTime) > AS "ConnectTimePct", >(SUM(WriteCompleTime - ConnectDoneTime) * 100) / SUM(EndTime - > StartTime) AS "R

Re: [BUGS] inconsistent composite type null handling in plpgsql out variable

On Fri, Aug 28, 2009 at 02:06:02PM -0400, Merlin Moncure wrote: > 3) If we decide the sql standard is correct, so that (null, null) is > null == true, then we should observe rule 1 and make things work in > consistent way. This means, for example, that null::foo and (null, > null)::foo should not

Re: [BUGS] inconsistent composite type null handling in plpgsql out variable

2009/8/31 Sam Mason : > On Fri, Aug 28, 2009 at 02:06:02PM -0400, Merlin Moncure wrote: >> 3) If we decide the sql standard is correct, so that (null, null) is >> null == true, then we should observe rule 1 and make things work in >> consistent way.  This means, for example, that null::foo and (nul

[BUGS] lost statistics; analyze needs to execute twice

Hi, pgsql 8.3.7 and 8.4.0 when i issue an "immediate shutdown" the statistics on all tables disappear... and when i try to recover them via an analyze; (on all tables on the database) the result is nothing... i have to exexute the analyze commands twice to compute the statistics jd=# select rel

[BUGS] BUG #5023: pg_relation_size() is not case sensitive

The following bug has been logged online: Bug reference: 5023 Logged by: Joseph Shraibman Email address: j...@selectacast.net PostgreSQL version: 8.3.7 Operating system: Linux Description:pg_relation_size() is not case sensitive Details: The pg_relation_size(text)

Re: [BUGS] BUG #5023: pg_relation_size() is not case sensitive

"Joseph Shraibman" wrote: > The pg_relation_size(text) method cannot determine the size of a > relation that has capital letters. Did you try putting quotes inside the apostrophes?: SELECT pg_relation_size('"MixedCaseRelation"'); -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@po

Re: [BUGS] BUG #5023: pg_relation_size() is not case sensitive

Joseph Shraibman wrote: > Kevin Grittner wrote: >> Did you try putting quotes inside the apostrophes?: >> > No, I didn't. I didn't know I could do that. That's generally true in recent versions. (Try the -t option on pg_dump for the first place I ran into it.) Perhaps it should be documen

Re: [BUGS] BUG #5023: pg_relation_size() is not case sensitive

Kevin Grittner wrote: "Joseph Shraibman" wrote: The pg_relation_size(text) method cannot determine the size of a relation that has capital letters. Did you try putting quotes inside the apostrophes?: No, I didn't. I didn't know I could do that. SELECT pg_relation_size('"MixedCaseRela

[BUGS] BUG #5024: Aggregate function FROM subquery

The following bug has been logged online: Bug reference: 5024 Logged by: Sheng Y. Cheng Email address: sch...@adconion.com PostgreSQL version: 8.4.0 / 8.3.1 Operating system: Red Hat 4.1.1-52 Description:Aggregate function FROM subquery Details: Here are some facts

[BUGS] BUG #5025: Aggregate function with subquery in 8.3 and 8.4.

The following bug has been logged online: Bug reference: 5025 Logged by: Sheng Y. Cheng Email address: sch...@adconion.com PostgreSQL version: 8.4.0 / 8.3.1 Operating system: Red Hat 4.1.1-52 Description:Aggregate function with subquery in 8.3 and 8.4. Details: Here

Re: [BUGS] BUG #4919: CREATE USER command slows down system performance

Lauris Ulmanis wrote: > When user count in Postgres database reaches up to 500 000 - database > command of creating users 'CREATE USER' slows down to 5-10 seconds per user. A bunch of commits along the direction of eliminating what we thought was the main cause of the slowdown have just concluded

Re: [BUGS] psql: FATAL: the database system is in recovery mode

Hi, Sorry for the insufficient information. As follows is the infomrations: - What version of PostgreSQL you are using? #rpm -qa|grep postgres postgresql-server-8.0.3-1 postgresql-libs-8.0.3-1 postgresql-odbc-08.00.0100-1 postgresql-jdbc-8.0.3-1 postgresql-docs-8.0.3-1 postgresql-tcl-8.0.3-1 postg

Re: [BUGS] psql: FATAL: the database system is in recovery mode

Bhushan Verma writes: > - What version of PostgreSQL you are using? > #rpm -qa|grep postgres > postgresql-server-8.0.3-1 8.0.3 is four years obsolete. If you can still reproduce the crash after updating to some recent 8.0.x version, it'd be worth looking closer. regards,

Re: [BUGS] psql: FATAL: the database system is in recovery mode

Hi, Sorry that was for my fedora 4 machine. But my fedora 9 machine have as follows postgres version. rpm -qa|grep postgres postgresql-server-8.3.1-1.fc9.i386 postgresql-devel-8.3.1-1.fc9.i386 postgresql-python-8.3.1-1.fc9.i386 postgresql-8.3.1-1.fc9.i386 postgresql-libs-8.3.1-1.fc9.i386 I am ge

Re: [BUGS] psql: FATAL: the database system is in recovery mode

On Tue, Sep 1, 2009 at 8:47 AM, Bhushan Verma wrote: > But my fedora 9 machine have as follows postgres version. > rpm -qa|grep postgres > postgresql-server-8.3.1-1.fc9.i386 > postgresql-devel-8.3.1-1.fc9.i386 > postgresql-python-8.3.1-1.fc9.i386 > postgresql-8.3.1-1.fc9.i386 > postgresql-libs-8.3.