|
14 | 14 | alink="#0000ff">
|
15 | 15 | <H1>Frequently Asked Questions (FAQ) for PostgreSQL</H1>
|
16 | 16 |
|
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> |
18 | 18 |
|
19 | 19 | <P>Current maintainer: Bruce Momjian (<A href=
|
20 | 20 | "mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
|
@@ -82,7 +82,7 @@ <H2 align="center">Administrative Questions</H2>
|
82 | 82 | <A href="#3.9">3.9</A>) What are the <I>pg_sorttempNNN.NN</I>
|
83 | 83 | files in my database directory?<BR>
|
84 | 84 | <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> |
86 | 86 |
|
87 | 87 |
|
88 | 88 | <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>
|
786 | 786 | running at the time, it is safe to delete the pg_tempNNN.NN
|
787 | 787 | files.</P>
|
788 | 788 |
|
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. |
807 | 804 |
|
808 | 805 | <HR>
|
809 | 806 |
|
|
0 commit comments