1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
8
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
10
HREF="mailto:pgsql-docs@postgresql.org"><LINK
12
TITLE="PostgreSQL 9.1beta1 Documentation"
13
HREF="index.html"><LINK
15
TITLE="Additional Supplied Modules"
16
HREF="contrib.html"><LINK
19
HREF="pgtrgm.html"><LINK
25
HREF="stylesheet.css"><META
26
HTTP-EQUIV="Content-Type"
27
CONTENT="text/html; charset=ISO-8859-1"><META
29
CONTENT="2011-04-27T21:20:33"></HEAD
35
SUMMARY="Header navigation table"
47
>PostgreSQL 9.1beta1 Documentation</A
66
TITLE="Additional Supplied Modules"
74
>Appendix F. Additional Supplied Modules</TD
80
TITLE="Additional Supplied Modules"
111
> (formerly called <SPAN
118
> data files to be upgraded to a later <SPAN
122
major version without the data dump/reload typically required for
123
major version upgrades, e.g. from 8.4.7 to the current major release
127
>. It is not required for minor version upgrades, e.g. from
131
> Major PostgreSQL releases regularly add new features that often
132
change the layout of the system tables, but the internal data storage
133
format rarely changes. <SPAN
137
to perform rapid upgrades by creating new system tables and simply
138
reusing the old user data files. If a future major release ever
139
changes the data storage format in a way that makes the old data
140
format unreadable, <SPAN
144
for such upgrades. (The community will attempt to avoid such
152
make sure the old and new clusters are binary-compatible, e.g. by
153
checking for compatible compile-time settings, including 32/64-bit
154
binaries. It is important that
155
any external modules are also binary compatible, though this cannot
167
>F.36.1. Supported Versions</A
170
> pg_upgrade supports upgrades from 8.3.X and later to the current
171
major release of <SPAN
174
>, including snapshot and alpha releases.
193
> accepts the following command-line arguments:
220
>specify the old cluster executable directory</P
242
>specify the new cluster executable directory</P
254
>check clusters only, don't change any data</P
276
>specify the old cluster data directory</P
298
>specify the new cluster data directory</P
332
>output debugging activity to file</P
344
>link instead of copying files to new cluster</P
366
>log session activity to file</P
388
>specify the old cluster port number</P
410
>specify the new cluster port number</P
432
>clusters superuser</P
444
>enable verbose output</P
456
>display version information, then exit</P
471
>show help, then exit</P
484
>F.36.3. Upgrade Steps</A
494
>Optionally move the old cluster</B
497
> If you are using a version-specific installation directory, e.g.
500
>/opt/PostgreSQL/8.4</TT
501
>, you do not need to move the old cluster. The
502
one-click installers all use version-specific installation directories.
505
> If your installation directory is not version-specific, e.g.
508
>/usr/local/pgsql</TT
509
>, it is necessary to move the current PostgreSQL install
510
directory so it does not interfere with the new <SPAN
514
Once the current <SPAN
517
> server is shut down, it is safe to rename the
518
PostgreSQL installation directory; assuming the old directory is
521
>/usr/local/pgsql</TT
525
CLASS="PROGRAMLISTING"
526
>mv /usr/local/pgsql /usr/local/pgsql.old</PRE
528
to rename the directory.
535
>For source installs, build the new version</B
538
> Build the new PostgreSQL source with <TT
541
> flags that are compatible
542
with the old cluster. <SPAN
549
sure all settings are compatible before starting the upgrade.
556
>Install the new PostgreSQL binaries</B
559
> Install the new server's binaries and support files. You can use the
560
same port numbers for both clusters, typically 5432, because the old and
561
new clusters will not be running at the same time.
564
> For source installs, if you wish to install the new server in a custom
565
location, use the <TT
571
CLASS="PROGRAMLISTING"
572
>gmake prefix=/usr/local/pgsql.new install</PRE
580
>Install pg_upgrade and pg_upgrade_support</B
589
>pg_upgrade_support</SPAN
590
> library in the new PostgreSQL cluster.
597
>Initialize the new PostgreSQL cluster</B
600
> Initialize the new cluster using <TT
604
Again, use compatible <TT
608
flags that match the old cluster. Many
609
prebuilt installers do this step automatically. There is no need to
610
start the new cluster.
617
>Install custom shared object files</B
620
> Install any custom shared object files (or DLLs) used by the old cluster
621
into the new cluster, e.g. <TT
624
>, whether they are from <TT
628
or some other source. Do not install the schema definitions, e.g.
632
>, because these will be upgraded from the old cluster.
639
>Adjust authentication</B
645
> will connect to the old and new servers several times,
646
so you might want to set authentication to <TT
661
HREF="libpq-pgpass.html"
664
to avoid being prompted repeatedly for a password.
671
>Stop both servers</B
674
> Make sure both database servers are stopped using, on Unix, e.g.:
677
CLASS="PROGRAMLISTING"
678
>pg_ctl -D /opt/PostgreSQL/8.4 stop
679
pg_ctl -D /opt/PostgreSQL/9.0 stop</PRE
682
or on Windows, using the proper service names:
685
CLASS="PROGRAMLISTING"
686
>NET STOP postgresql-8.4
687
NET STOP postgresql-9.0</PRE
693
CLASS="PROGRAMLISTING"
694
>NET STOP pgsql-8.3 (<SPAN
697
> 8.3 and older used a different service name)</PRE
711
> Always run the <SPAN
714
> binary of the new server, not the old one.
718
> requires the specification of the old and new cluster's
719
data and executable (<TT
722
>) directories. You can also specify separate
723
user and port values, and whether you want the data linked instead of
724
copied (the default). If you use linking, the upgrade will be much
725
faster (no data copying), but you will no longer be able to access your
726
old cluster once you start the new cluster after the upgrade. See
729
>pg_upgrade --help</TT
730
> for a full list of options.
733
> For Windows users, you must be logged into an administrative account, and
734
then start a shell as the <TT
737
> user and set the proper path:
740
CLASS="PROGRAMLISTING"
741
>RUNAS /USER:postgres "CMD.EXE"
742
SET PATH=%PATH%;C:\Program Files\PostgreSQL\9.0\bin;</PRE
748
> with quoted directories, e.g.:
751
CLASS="PROGRAMLISTING"
753
--old-datadir "C:/Program Files/PostgreSQL/8.4/data"
754
--new-datadir "C:/Program Files/PostgreSQL/9.0/data"
755
--old-bindir "C:/Program Files/PostgreSQL/8.4/bin"
756
--new-bindir "C:/Program Files/PostgreSQL/9.0/bin"</PRE
762
> will verify the two clusters are compatible
763
and then do the upgrade. You can use <TT
765
>pg_upgrade --check</TT
767
to perform only the checks, even if the old server is still
770
>pg_upgrade --check</TT
771
> will also outline any
772
manual adjustments you will need to make after the upgrade.
776
> requires write permission in the current directory.
779
> Obviously, no one should be accessing the clusters during the upgrade.
782
> If an error occurs while restoring the database schema, <TT
786
exit and you will have to revert to the old cluster as outlined in <A
787
HREF="pgupgrade.html#PGUPGRADE-STEP-REVERT"
793
> again, you will need to modify the old
794
cluster so the pg_upgrade schema restore succeeds. If the problem is a
795
contrib module, you might need to uninstall the contrib module from
796
the old cluster and install it in the new cluster after the upgrade,
797
assuming the module is not being used to store user data.
810
> If you modified <TT
817
restore its original authentication settings.
824
>Post-Upgrade processing</B
827
> If any post-upgrade processing is required, pg_upgrade will issue
828
warnings as it completes. It will also generate script files that must
829
be run by the administrator. The script files will connect to each
830
database that needs post-upgrade processing. Each script should be
834
CLASS="PROGRAMLISTING"
835
>psql --username postgres --file script.sql postgres</PRE
838
The scripts can be run in any order and can be deleted once they have
860
> In general it is unsafe to access tables referenced in rebuild scripts
861
until the rebuild scripts have run to completion; doing so could yield
862
incorrect results or poor performance. Tables not referenced in rebuild
863
scripts can be accessed immediately.
877
> Because optimizer statistics are not transferred by <TT
881
be instructed to run a command to regenerate that information at the end
889
>Delete old cluster</B
892
> Once you are satisfied with the upgrade, you can delete the old
893
cluster's data directories by running the script mentioned when
897
> completes. You can also delete the
898
old installation directories
911
NAME="PGUPGRADE-STEP-REVERT"
915
>Reverting to old cluster</B
918
> If, after running <TT
921
>, you wish to revert to the old cluster,
922
there are several options:
936
>, no modifications were made to the old
937
cluster and you can re-use it anytime.
949
>, the data files are shared between the
950
old and new cluster. If you started the new cluster, the new
951
server has written to those shared files and it is unsafe to
971
or did not start the new server, the old cluster was not
972
modified except that an <TT
975
> suffix was appended
978
>$PGDATA/global/pg_control</TT
980
tablespace directories. To reuse the old cluster, remove
987
>$PGDATA/global/pg_control</TT
989
to 8.4 or earlier, remove the tablespace directories created
990
by the upgrade and remove the <TT
994
the tablespace directory names; then you can restart the old
1011
>F.36.4. Limitations in Upgrading <SPAN
1020
> Upgrading from PostgreSQL 8.3 has additional restrictions not present
1021
when upgrading from later PostgreSQL releases. For example,
1022
pg_upgrade will not work for upgrading from 8.3 if a user column
1040
> and is not the first column
1047
> You must drop any such columns and upgrade them manually.
1050
> pg_upgrade will require a table rebuild if:
1056
> a user column is of data type <TT
1066
> pg_upgrade will require a reindex if:
1072
> an index is of type hash or GIN
1077
> an index uses <CODE
1079
>bpchar_pattern_ops</CODE
1087
> Also, the default datetime storage format changed to integer after
1091
> 8.3. pg_upgrade will check that the datetime storage format
1092
used by the old and new clusters match. Make sure your new cluster is
1093
built with the configure flag <TT
1095
>--disable-integer-datetimes</TT
1099
> For Windows users, note that due to different integer datetimes settings
1100
used by the one-click installer and the MSI installer, it is only
1101
possible to upgrade from version 8.3 of the one-click distribution to
1102
version 8.4 or later of the one-click distribution. It is not
1103
possible to upgrade from the MSI installer to the one-click installer.
1118
> does not support upgrading of databases
1119
containing these <TT
1122
> OID-referencing system data types:
1152
> All failure, rebuild, and reindex cases will be reported by
1156
> if they affect your installation;
1157
post-upgrade scripts to rebuild tables and indexes will be
1158
generated automatically.
1161
> For deployment testing, create a schema-only copy of the old cluster,
1162
insert dummy data, and upgrade that.
1165
> If you want to use link mode and you don't want your old cluster
1166
to be modified when the new cluster is started, make a copy of the
1167
old cluster and upgrade that with link mode. To make a valid copy
1168
of the old cluster, use <TT
1172
copy of the old cluster while the server is running, then shut down
1173
the old server and run <TT
1176
> again to update the copy with any
1177
changes to make it consistent.
1186
SUMMARY="Footer navigation table"
b'\\ No newline at end of file'