Add pg_dump/restore item to FAQ.

Martijn van Oosterhout

diff --git a/doc/src/FAQ/FAQ.html b/doc/src/FAQ/FAQ.html
index 32762e38ea2f97ac9dd99bb63969adb499cae80c..1eead79e05c6d0e80d4d64678c043421344ed531 100644 (file)
--- a/doc/src/FAQ/FAQ.html
+++ b/doc/src/FAQ/FAQ.html
@@ -81,6 +81,8 @@
     clients"</I> when trying to connect?<BR>
      <A href="#3.9">3.9</A>) What are the <I>pg_sorttempNNN.NN</I>
     files in my database directory?<BR>
+     <A href="#3.10">3.10</A>) Why do I need to do a dump and restore 
+    to upgrade PostgreSQL?<BR>
      
 
     <H2 align="center">Operational Questions</H2>
@@ -776,6 +778,26 @@
     not if a backend crashes during a sort. If you have no backends
     running at the time, it is safe to delete the pg_tempNNN.NN
     files.</P>
+
+    <H4><A name="3.10">3.10</A>) Why do I need to do a dump and restore 
+    to upgrade PostgreSQL?</H4>
+
+    <P>The PostgreSQL team tries very heard to maintain compatability across
+    minor releases. So upgrading from 7.2 to 7.2.1 does not require a dump a
+    restore. However, new features are continuously being adding and
+    sometimes this requires new fields to be added to system tables.
+
+    <P>These changes may be across many tables and so maintaining backward
+    compatability would be quite difficult. Thus, restoring from a dump is
+    required to make everything work.
+
+    <P>Note that the actual on-disk file format does not change very often,
+    a feature the pg_upgrade script uses quite successfully. There the dump
+    is used create the necessary information in the system tables. The data
+    files are then just copied across. This method is not as guarenteed as
+    the dump/restore method but when it works it can make upgrades very
+    efficient.
+
     <HR>
 
     <H2 align="center">Operational Questions</H2>