|
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 (<Ahref= |
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 | <Ahref="#3.9">3.9</A>) What are the<I>pg_sorttempNNN.NN</I> |
83 | 83 | files in my database directory?<BR> |
84 | 84 | <Ahref="#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 | <H2align="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><Aname="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><Aname="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 |
|
|