diff --git a/doc/src/sgml/pgupgrade.sgml b/doc/src/sgml/pgupgrade.sgml
new file mode 100644
index e1cd260..4e4fe64
*** a/doc/src/sgml/pgupgrade.sgml
--- b/doc/src/sgml/pgupgrade.sgml
*************** pg_upgrade.exe
*** 409,414 ****
--- 409,486 ----
     </step>

     <step>
+     <title>Upgrade any Log-Shipping Standby Servers</title>
+ 
+     <para>
+      If you have Log-Shipping Standby Servers (<xref
+      linkend="warm-standby">), follow these steps to upgrade them (before
+      starting any servers):
+     </para>
+ 
+     <procedure>
+ 
+      <step>
+       <title>Install the new PostgreSQL binaries on standby servers</title>
+ 
+       <para>
+        Make sure the new binaries and support files are installed
+        on all the standby servers.  Do <emphasis>not</> run
+        <application>initdb</>.  If <application>initdb</> was run, delete
+        the standby server data directories.  Also, install any custom
+        shared object files on the new standbys that you installed in the
+        new master cluster.
+       </para>
+      </step>
+ 
+      <step>
+       <title>Run <application>rsync</></title>
+ 
+       <para>
+        From a directory that is above the old and new database cluster
+        directories, run this for each slave:
+ 
+ <programlisting>
+        rsync --archive --hard-links --size-only old_dir new_dir remote_dir
+ </programlisting>
+ 
+        where <option>old_dir</> and <option>new_dir</> are relative
+        to the current directory, and <option>remote_dir</> is
+        <emphasis>above</> the old and new cluster directories on
+        the standby server.  The old and new relative cluster paths
+        must match on the master and standby server.  Consult the
+        <application>rsync</> manual page for details on specifying the
+        remote directory, e.g. <literal>slavehost:/var/lib/postgresql/</>.
+        <application>rsync</> will be fast when <option>--link</> mode is
+        used because it will create hard links on the remote server rather
+        than transfering user data.
+       </para>
+      </step>
+ 
+      <step>
+       <title>Configure log-shipping to standby servers</title>
+ 
+       <para>
+        Configure the servers for log shipping.  (You do not need to run
+        <function>pg_start_backup()</> and <function>pg_stop_backup()</>
+        or take a file system backup as the slaves are still sychronized
+        with the master.)
+       </para>
+      </step>
+ 
+     </procedure>
+ 
+    </step>
+ 
+    <step>
+     <title>Start the new server</title>
+ 
+     <para>
+      The new server and any <application>rsync</>'ed standby servers can
+      now be safely started.
+     </para>
+    </step>
+ 
+    <step>
      <title>Post-Upgrade processing</title>

      <para>
*************** psql --username postgres --file script.s
*** 548,562 ****
    </para>

    <para>
-    A Log-Shipping Standby Server (<xref linkend="warm-standby">) cannot
-    be upgraded because the server must allow writes.  The simplest way
-    is to upgrade the primary and use <command>rsync</> to rebuild the
-    standbys.  You can run <command>rsync</> while the primary is down,
-    or as part of a base backup (<xref linkend="backup-base-backup">)
-    which overwrites the old standby cluster.
-   </para>
- 
-   <para>
     If you want to use link mode and you do not want your old cluster
     to be modified when the new cluster is started, make a copy of the
     old cluster and upgrade that in link mode. To make a valid copy
--- 620,625 ----