@@ -81,6 +81,8 @@ <H2 align="center">Administrative Questions</H2>
8181 clients"</ I > when trying to connect?< BR >
8282< A href ="#3.9 "> 3.9</ A > ) What are the< I > pg_sorttempNNN.NN</ I >
8383 files in my database directory?< BR >
84+ < A href ="#3.10 "> 3.10</ A > ) Why do I need to do a dump and restore
85+ to upgrade PostgreSQL?< BR >
8486
8587
8688< H2 align ="center "> Operational Questions</ H2 >
@@ -776,6 +778,26 @@ <H4><A name="3.9">3.9</A>) What are the <I>pg_sorttempNNN.NN</I>
776778 not if a backend crashes during a sort. If you have no backends
777779 running at the time, it is safe to delete the pg_tempNNN.NN
778780 files.</ P >
781+
782+ < H4 > < A name ="3.10 "> 3.10</ A > ) Why do I need to do a dump and restore
783+ to upgrade PostgreSQL?</ H4 >
784+
785+ < P > The PostgreSQL team tries very heard to maintain compatability across
786+ minor releases. So upgrading from 7.2 to 7.2.1 does not require a dump a
787+ restore. However, new features are continuously being adding and
788+ sometimes this requires new fields to be added to system tables.
789+
790+ < P > These changes may be across many tables and so maintaining backward
791+ compatability would be quite difficult. Thus, restoring from a dump is
792+ required to make everything work.
793+
794+ < P > Note that the actual on-disk file format does not change very often,
795+ a feature the pg_upgrade script uses quite successfully. There the dump
796+ is used create the necessary information in the system tables. The data
797+ files are then just copied across. This method is not as guarenteed as
798+ the dump/restore method but when it works it can make upgrades very
799+ efficient.
800+
779801< HR >
780802
781803< H2 align ="center "> Operational Questions</ H2 >