Add pg_dump/restore item to FAQ.

Martijn van Oosterhout

1 files changed, 22 insertions, 0 deletions

diff --git a/doc/src/FAQ/FAQ.html b/doc/src/FAQ/FAQ.html
index 32762e38ea2..1eead79e05c 100644
--- 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>