[ADMIN] Migration from 7.4.2 to 8.1.4
Hi! I'm an administrator of a big company who has a PgSQL-database version 7.4.2. We would like to upgrade it to 8.1.4 but the dumpwe made cannot be restored.We got a lot of error messages while restoring database related on something's being restored before other objects would exists. (??? ) We have made some changes in the dump reversing creation processes and it seems to be useful but there's a lot of error messages onthe same problemand do not have time to do them all by hand. Weneed help to convert this dump for us (I can provide binarydata if needed) to be able use it with the new system. We would pay this conversion. Thanks in advance, John Gallai, System administrator Mediagnost Ltd, Budapest, Hungary
[ADMIN] Correct JDBC driver for
Hello,One of our Java developers is having trouble inserting data to postgres 7.4.13 (running on Gentoo linux). The Java version being used is 1.4.The proble is with 'backslash_quote = off' the database is rejecting the data sent from the Java application. Within the application we don't use " \ " to escape. So we suspected that may be " \ " is being inserted by the JDBC driver.The driver we use is pg74.216.jdbc3.jar http://jdbc.postgresql.org/download/pg74.216.jdbc3.jarCould this be an issue with the driver?Thanks and regards,-Thusitha
Re: [ADMIN] Migration from 7.4.2 to 8.1.4
Am Montag, 21. August 2006 11:43 schrieb Gallai János: I'm an administrator of a big company who has a PgSQL-database version 7.4.2. We would like to upgrade it to 8.1.4 but the dump we made cannot be restored. We got a lot of error messages while restoring database related on something's being restored before other objects would exists. You should have more success if you use the pg_dump(all) program from 8.1.4 to create the dump. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] Migration from 7.4.2 to 8.1.4
On Mon, Aug 21, 2006 at 11:43:28AM +0200, Gallai János wrote: I'm an administrator of a big company who has a PgSQL-database version 7.4.2. We would like to upgrade it to 8.1.4 but the dump we made cannot be restored. Which version of pg_dump/pg_dumpall did you use? When upgrading use the newer version (i.e., use 8.1.4's pg_dump against the 7.4.2 database). -- Michael Fuhr ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[ADMIN] unsubscribe
Juan Pablo Grassi __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[ADMIN] Vacuum issues..
Hi, I am using PostgreSQL 8.1.4 for an embedded application. For some reason, vacuum is not able to identify rows that are candidates for removal (i.e., mark space as available). Background Info: I observed some performance problems our database seemed to be using an unusually high amount of cpu. Further investigation of the problem revealed a very bloated database; the database was around 300M when it should have been about 150M. A number of the database files were quite large, however, the tables that they stored information for were very small. For example, we had one table that had only 46 rows, but was using up more than 17M of disk space. We had a number of other tables that were similarly large. We run auto vacuum and I can see from the logs that it is running quite frequently. When I run vacuum full from the psql, I can see that space is not being recovered. I have run vacuum full with the verbose flag set, I can see that messages that indicate the existence of dead row versions that cannot be removed yet. --- CUT FROM VACUUM OUTPUT --- CPU 0.00s/0.00u sec elapsed 0.18 sec. INFO: ibportreceivestatsca: found 0 removable, 88017 nonremovable row versions in 4001 pages DETAIL: 87957 dead row versions cannot be removed yet. There were 1 unused item pointers. --- CUT FROM VACUUM OUTPUT --- If I shutdown our application and run a vacuum full, the space is recovered and the database size goes down to 150M. So, my best guess is that something in our application is preventing vacuum from removing dead rows. What could cause this? Would it be caused by a long-living transaction? What is the best way to track the problem down...right now, I am looking through pg_stat_activity and pg_locks to find processes that are in transaction and what locks they are holding. Has anyone had a similar problem? If so, how did you resolve it? Thanks Ike
Re: [ADMIN] Vacuum issues..
Eamonn Kent wrote: I am using PostgreSQL 8.1.4 for an embedded application. For some reason, vacuum is not able to identify rows that are candidates for removal (i.e., mark space as available). [snip] If I shutdown our application and run a vacuum full, the space is recovered and the database size goes down to 150M. The most common answer to this is that your application is leaving open transactions just sitting there. VACUUM can't remove tuples that may still need to be visible to a transaction that's been open for days. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[ADMIN] unsubscribe
Unsubscribe R Mohan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[ADMIN] Max User Connections
Hi, I have set Max Connection parameter as 1000 in Postgres.conf file. But it only allows max connections to be 155. I have increased Shared buffer parameter also. I am not able to find out a solution to this problem. I have searched in the archives as well. Do I need to increase the Shared memory in Windows, as I am running my application on windows. Please anyone let me know about this. Thanks Vishal ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[ADMIN] unsubscribe
Unsubscribe Jayaram ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
