Zen

Source string Source string

284/10000 · 284

The string is read only.

English Actions
If you can't find the <filename>postgis_upgrade.sql</filename> specific for upgrading your version you are using a version too early for a soft upgrade and need to do a <link linkend="hard_upgrade">HARD UPGRADE</link>.
The <xref linkend="PostGIS_Full_Version"/> function should inform you about the need to run this kind of upgrade using a "procs need upgrade" message.
Hard upgrade
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 <link linkend="release_notes">Release Notes</link> appendix reports for each version whether you need a dump/reload (HARD UPGRADE) to upgrade.
The dump/reload process is assisted by the postgis_restore script which takes care of skipping from the dump all definitions which belong to PostGIS (including old ones), allowing you to restore your schemas and data into a database with PostGIS installed without getting duplicate symbol errors or bringing forward deprecated objects.
Supplementary instructions for windows users are available at <link xlink:href="http://trac.osgeo.org/postgis/wiki/UsersWikiWinUpgrade">Windows Hard upgrade</link>.
The Procedure is as follows:
Create a "custom-format" dump of the database you want to upgrade (let's call it <varname>olddb</varname>) include binary blobs (-b) and verbose (-v) output. The user can be the owner of the db, need not be postgres super account.
Do a fresh install of PostGIS in a new database -- we'll refer to this database as <varname>newdb</varname>. Please refer to <xref linkend="create_new_db"/> and <xref linkend="create_new_db_extensions"/> for instructions on how to do this.
The spatial_ref_sys entries found in your dump will be restored, but they will not override existing ones in spatial_ref_sys. This is to ensure that fixes in the official set will be properly propagated to restored databases. If for any reason you really want your own overrides of standard entries just don't load the spatial_ref_sys.sql file when creating the new db.
If your database is really old or you know you've been using long deprecated functions in your views and functions, you might need to load <filename>legacy.sql</filename> for all your functions and views etc. to properly come back. Only do this if _really_ needed. Consider upgrading your views and functions before dumping instead, if possible. The deprecated functions can be later removed by loading <filename>uninstall_legacy.sql</filename>.
Restore your backup into your fresh <varname>newdb</varname> database using postgis_restore. Unexpected errors, if any, will be printed to the standard error stream by psql. Keep a log of those.
Errors may arise in the following cases:
Some of your views or functions make use of deprecated PostGIS objects. In order to fix this you may try loading <filename>legacy.sql</filename> script prior to restore or you'll have to restore to a version of PostGIS which still contains those objects and try a migration again after porting your code. If the <filename>legacy.sql</filename> way works for you, don't forget to fix your code to stop using deprecated functions and drop them loading <filename>uninstall_legacy.sql</filename>.
Some custom records of spatial_ref_sys in dump file have an invalid SRID value. Valid SRID values are bigger than 0 and smaller than 999000. Values in the 999000.999999 range are reserved for internal use while values &gt; 999999 can't be used at all. All your custom records with invalid SRIDs will be retained, with those &gt; 999999 moved into the reserved range, but the spatial_ref_sys table would lose a check constraint guarding for that invariant to hold and possibly also its primary key ( when multiple invalid SRIDS get converted to the same reserved SRID value ).
In order to fix this you should copy your custom SRS to a SRID with a valid value (maybe in the 910000..910999 range), convert all your tables to the new srid (see <xref linkend="UpdateGeometrySRID"/>), delete the invalid entry from spatial_ref_sys and re-construct the check(s) with:
If you are upgrading an old database containing french <link xlink:href="https://en.wikipedia.org/wiki/Institut_g%C3%A9ographique_national"> IGN </link> cartography, you will have probably SRIDs out of range and you will see, when importing your database, issues like this :
In this case, you can try following steps : first throw out completely the IGN from the sql which is resulting from postgis_restore. So, after having run :
run this command :
Create then your newdb, activate the required Postgis extensions, and insert properly the french system IGN with : <link xlink:href="https://raw.githubusercontent.com/Remi-C/IGN_spatial_ref_for_PostGIS/master/Put_IGN_SRS_into_Postgis.sql"> this script </link> After these operations, import your data :
Performance Tuning
Tuning for PostGIS performance is much like tuning for any PostgreSQL workload. The only additional consideration is that geometries and rasters are usually large, so memory-related optimizations generally have more of an impact on PostGIS than other types of PostgreSQL queries.
For general details about optimizing PostgreSQL, refer to <link xlink:href="https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server">Tuning your PostgreSQL Server</link>.
For PostgreSQL 9.4+ configuration can be set at the server level without touching <code>postgresql.conf</code> or <code>postgresql.auto.conf</code> by using the <code>ALTER SYSTEM</code> command.
In addition to the Postgres settings, PostGIS has some custom settings which are listed in <xref linkend="PostGIS_GUC"/>.
Startup
These settings are configured in <code>postgresql.conf</code>:
constraint_exclusion
Default: partition
This is generally used for table partitioning. The default for this is set to "partition" which is ideal for PostgreSQL 8.4 and above since it will force the planner to only analyze tables for constraint consideration if they are in an inherited hierarchy and not pay the planner penalty otherwise.
shared_buffers

Loading…

User avatar None

String updated in the repository

  1. postgis
  2. PostGIS Manual
  3. English
In order to fix this you should copy your custom SRS to a SRID with a valid value (maybe in the 910000..910999 range), convert all your tables to the new srid (see <xref linkend="UpdateGeometrySRID"/>), delete the invalid entry from spatial_ref_sys and re-construct the check(s) with:
In order to fix this you should copy your custom SRS to a SRID with a valid value (maybe in the 910000..910999 range), convert all your tables to the new srid (see <xref linkend="UpdateGeometrySRID"/>), delete the invalid entry from spatial_ref_sys and re-construct the check(s) with:
a year ago
Browse all string changes

Things to check

Unpluralised

The string is used as plural, but not using plural forms

Reset

Glossary

English English
No related strings found in the glossary.

String information

Source string description
Tag: para
Flags
no-c-format, read-only
String age
a year ago
Last updated
a year ago
Source string age
a year ago
Translation file
doc/po/templates/postgis-manual.pot, string 66