Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 5530b0c

Browse files
committed
Improve wording of upgrade section.
1 parent 0f11129 commit 5530b0c

File tree

2 files changed

+33
-38
lines changed

2 files changed

+33
-38
lines changed

doc/FAQ

Lines changed: 16 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11

22
Frequently Asked Questions (FAQ) for PostgreSQL
33

4-
Last updated: Tue Jul 30 11:05:09 EDT 2002
4+
Last updated: Thu Aug 22 11:30:58 EDT 2002
55

66
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
77

@@ -53,7 +53,8 @@
5353
3.7) What debugging features are available?
5454
3.8) Why do I get "Sorry, too many clients" when trying to connect?
5555
3.9) What are the pg_sorttempNNN.NN files in my database directory?
56-
3.10) Why do I need to do a dump and restore to upgrade PostgreSQL?
56+
3.10) Why do I need to do a dump and restore to upgrade PostgreSQL
57+
releases?
5758

5859
Operational Questions
5960

@@ -602,23 +603,20 @@
602603
a backend crashes during a sort. If you have no backends running at
603604
the time, it is safe to delete the pg_tempNNN.NN files.
604605

605-
3.10) Why do I need to do a dump and restore to upgrade PostgreSQL?
606+
3.10) Why do I need to do a dump and restore to upgrade between major
607+
PostgreSQL releases?
606608

607-
The PostgreSQL team tries very heard to maintain compatability across
608-
minor releases. So upgrading from 7.2 to 7.2.1 does not require a dump
609-
a restore. However, new features are continuously being adding and
610-
sometimes this requires new fields to be added to system tables.
611-
612-
These changes may be across many tables and so maintaining backward
613-
compatability would be quite difficult. Thus, restoring from a dump is
614-
required to make everything work.
615-
616-
Note that the actual on-disk file format does not change very often, a
617-
feature the pg_upgrade script uses quite successfully. There the dump
618-
is used create the necessary information in the system tables. The
619-
data files are then just copied across. This method is not as
620-
guarenteed as the dump/restore method but when it works it can make
621-
upgrades very efficient.
609+
The PostgreSQL team makes only small changes between minor releases,
610+
so upgrading from 7.2 to 7.2.1 does not require a dump and restore.
611+
However, major releases often change the internal format of system
612+
tables and data files. These changes are often complex, so we don't
613+
maintain backward compatability for data files. A dump outputs data in
614+
a generic format that can then be loaded in using the new internal
615+
format.
616+
617+
In releases where the on-disk format does not change, the pg_upgrade
618+
script can be used to upgrade without a dump/restore. The release
619+
notes mention whether pg_upgrade is available for the release.
622620
_________________________________________________________________
623621

624622
Operational Questions

doc/src/FAQ/FAQ.html

Lines changed: 17 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@
1414
alink="#0000ff">
1515
<H1>Frequently Asked Questions (FAQ) for PostgreSQL</H1>
1616

17-
<P>Last updated: Tue Jul 30 11:05:09 EDT 2002</P>
17+
<P>Last updated: Thu Aug 22 11:30:58 EDT 2002</P>
1818

1919
<P>Current maintainer: Bruce Momjian (<A href=
2020
"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
@@ -82,7 +82,7 @@ <H2 align="center">Administrative Questions</H2>
8282
<A href="#3.9">3.9</A>) What are the <I>pg_sorttempNNN.NN</I>
8383
files in my database directory?<BR>
8484
<A href="#3.10">3.10</A>) Why do I need to do a dump and restore
85-
to upgrade PostgreSQL?<BR>
85+
to upgrade PostgreSQL releases?<BR>
8686

8787

8888
<H2 align="center">Operational Questions</H2>
@@ -786,24 +786,21 @@ <H4><A name="3.9">3.9</A>) What are the <I>pg_sorttempNNN.NN</I>
786786
running at the time, it is safe to delete the pg_tempNNN.NN
787787
files.</P>
788788

789-
<H4><A name="3.10">3.10</A>) Why do I need to do a dump and restore
790-
to upgrade PostgreSQL?</H4>
791-
792-
<P>The PostgreSQL team tries very heard to maintain compatability across
793-
minor releases. So upgrading from 7.2 to 7.2.1 does not require a dump a
794-
restore. However, new features are continuously being adding and
795-
sometimes this requires new fields to be added to system tables.
796-
797-
<P>These changes may be across many tables and so maintaining backward
798-
compatability would be quite difficult. Thus, restoring from a dump is
799-
required to make everything work.
800-
801-
<P>Note that the actual on-disk file format does not change very often,
802-
a feature the pg_upgrade script uses quite successfully. There the dump
803-
is used create the necessary information in the system tables. The data
804-
files are then just copied across. This method is not as guarenteed as
805-
the dump/restore method but when it works it can make upgrades very
806-
efficient.
789+
<H4><A name="3.10">3.10</A>) Why do I need to do a dump and restore
790+
to upgrade between major PostgreSQL releases?</H4>
791+
792+
<P>The PostgreSQL team makes only small changes between minor releases,
793+
so upgrading from 7.2 to 7.2.1 does not require a dump and restore.
794+
However, major releases often change the internal format of system
795+
tables and data files. These changes are often complex, so we don't
796+
maintain backward compatability for data files. A dump outputs data
797+
in a generic format that can then be loaded in using the new internal
798+
format.
799+
800+
<P>In releases where the on-disk format does not change, the
801+
<i>pg_upgrade</i> script can be used to upgrade without a dump/restore.
802+
The release notes mention whether <i>pg_upgrade</i> is available for the
803+
release.
807804

808805
<HR>
809806

0 commit comments

Comments
 (0)