From: Regina Obe Date: Sun, 19 Jun 2011 05:52:03 +0000 (+0000) Subject: Amend hard upgrade instructions to remove stuff that is obsolete and add in additiona... X-Git-Tag: 2.0.0alpha1~1398 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=371002231153cb3e6f098cf2b083fd69fd1f78f2;p=postgis Amend hard upgrade instructions to remove stuff that is obsolete and add in additional steps needed for PostGIS 2.0. Also update creating new spatial database to include instructions for installing raster and topology support git-svn-id: http://svn.osgeo.org/postgis/trunk@7428 b70326c6-7e19-0410-871a-916f4a2858ee --- diff --git a/doc/installation.xml b/doc/installation.xml index 4f6f60429..c497f1c6e 100644 --- a/doc/installation.xml +++ b/doc/installation.xml @@ -699,7 +699,7 @@ Failed: 0 - + Create a spatially-enabled database @@ -715,7 +715,7 @@ Failed: 0 Many of the PostGIS functions are written in the PL/pgSQL procedural language. As such, the next step to create a PostGIS database is to enable the PL/pgSQL language in your new database. This is accomplish by the - command + command below command. For PostgreSQL 8.4+, this is generally already installed @@ -754,6 +754,39 @@ Failed: 0 psql -d [yourdatabase] -f postgis_comments.sql + + + Install raster support + + + + psql -d [yourdatabase] -f rtpostgis.sql + + + + Install raster support comments. This will provide quick help info for each raster function + using psql or PgAdmin or any other PostgreSQL tool that can show function comments + + + + psql -d [yourdatabase] -f raster_comments.sql + + + Install topology support + + + + psql -d [yourdatabase] -f topology/topology.sql + + + + Install topology support comments. This will provide quick help info for each topology function / type + using psql or PgAdmin or any other PostgreSQL tool that can show function comments + + + + psql -d [yourdatabase] -f topology/topology_comments.sql + @@ -804,7 +837,7 @@ Failed: 0 Before attempting to upgrade PostGIS, it is always worth to backup your data. If you use the -Fc flag to pg_dump you will always be able to - restore the dump with an HARD UPGRADE. + restore the dump with a HARD UPGRADE. @@ -813,25 +846,16 @@ Failed: 0 After compiling you should find several postgis_upgrade*.sql files. Install the one for your version of PostGIS. For example postgis_upgrade_13_to_15.sql should be used if you are upgrading - from PostGIS 1.3 to 1.5. + from PostGIS 1.3 to 1.5. If you are moving from PostGIS 1.* to PostGIS 2.* or from PostGIS 2.* prior to r7409, you need to do a HARD UPGRADE. - $ psql -f postgis_upgrade_13_to_15.sql -d your_spatial_database - - - If a soft upgrade is not possible the script will abort and you will be - warned about HARD UPGRADE being required, so do not hesitate to try a - soft upgrade first. - + psql -f postgis_upgrade_20_minor.sql -d your_spatial_database - If you can't find the postgis_upgrade*.sql files - you are probably using a version prior to 1.1 and must generate that - file by yourself. This is done with the following command: + If you can't find the postgis_upgrade*.sql specific for upgrading your version you are using a version too early for + a soft upgrade and need to do a HARD UPGRADE. - - $ utils/postgis_proc_upgrade.pl postgis.sql > postgis_upgrade.sql @@ -839,8 +863,8 @@ Failed: 0 Hard upgrade - By HARD UPGRADE we intend full dump/reload of postgis-enabled databases. - You need an HARD UPGRADE when PostGIS objects' internal storage changes + By HARD UPGRADE we mean full dump/reload of postgis-enabled databases. + You need a HARD UPGRADE when PostGIS objects' internal storage changes or when SOFT UPGRADE is not possible. The Release Notes appendix reports for each version whether you need a dump/reload (HARD @@ -855,52 +879,29 @@ Failed: 0 Create a "custom-format" dump of the database you want to upgrade (let's - call it "olddb") - - - $ pg_dump -Fc olddb > olddb.dump - - - Restore the dump contextually upgrading PostGIS into a new database. The - new database doesn't have to exist. postgis_restore accepts createdb - parameters after the dump file name, and that can for instance be used - if you are using a non-default character encoding for your database. - Let's call it "newdb", with UNICODE as the character encoding: + call it "olddb") include binary blobs (-b) and verbose (-v) output. The user can be the owner of the db, need not be postgres + super account. - $ sh utils/postgis_restore.pl postgis.sql newdb olddb.dump -E=UNICODE > restore.log + pg_dump -h localhost -p 5432 -U postgres -Fc -b -v -f "/somepath/olddb.backup" olddb + + If you made custom entries to your spatial_ref_sys.sql, you may want to backup this table separately or copy out the custom records. + The spatial_ref_sys you will end up with will be the new one packaged with the PostGIS install. - - Check that all restored dump objects really had to be restored from dump - and do not conflict with the ones defined in postgis.sql - + Do a fresh install of PostGIS in a new database -- we'll refer to this database as newdb. + Please refer to for instructions on how to do this. + + Restore your backup into your fresh newdb database using pg_restore. - $ grep ^KEEPING restore.log | less + pg_restore -h localhost -p 5432 -U postgres -d newdb "/somepath/olddb.backup" - - If upgrading from PostgreSQL < 8.0 to >= 8.0 you might want to - drop the attrelid, varattnum and stats columns in the geometry_columns - table, which are no-more needed. Keeping them won't hurt. DROPPING THEM - WHEN REALLY NEEDED WILL DO HURT ! - - - $ psql newdb -c "ALTER TABLE geometry_columns DROP attrelid" -$ psql newdb -c "ALTER TABLE geometry_columns DROP varattnum" -$ psql newdb -c "ALTER TABLE geometry_columns DROP stats" - - - spatial_ref_sys table is restore from the dump, to ensure your custom - additions are kept, but the distributed one might contain modification - so you should backup your entries, drop the table and source the new - one. If you did make additions we assume you know how to backup them - before upgrading the table. Replace of it with the new one is done like - this: - + Finally run the uninstall_legacy.sql script in this new database. NOTE: This step is + important even if you plan to reinstall legacy functions. This is because many functions have been revised to use default parameters, and + your old install would therefore restore these which would result in ambiguous name conflicts when called. + psql -h localhost -p 5432 -U postgres -d newdb -f uninstall_legacy.sql - $ psql newdb -newdb=> truncate spatial_ref_sys; -DROP -newdb=> \i spatial_ref_sys.sql + If your applications or GIS tools rely on old deprecated functions, you can restore these back with + psql -h localhost -p 5432 -U postgres -d newdb -f legacy.sql