From c9ab1f957a7f1836e29aca460c25f28a96b2b2af Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date: Fri, 16 Jan 2015 18:16:40 +0200
Subject: [PATCH] Use standard top-level sections in reference page.

---
 doc/src/sgml/ref/pg_rewind.sgml | 90 ++++++++++++++++-----------------
 1 file changed, 45 insertions(+), 45 deletions(-)

diff --git a/doc/src/sgml/ref/pg_rewind.sgml b/doc/src/sgml/ref/pg_rewind.sgml
index 686cf2a0e2..4458ae0d56 100644
--- a/doc/src/sgml/ref/pg_rewind.sgml
+++ b/doc/src/sgml/ref/pg_rewind.sgml
@@ -107,9 +107,9 @@ PostgreSQL documentation
       <term><option>--source-pgdata</option></term>
       <listitem>
        <para>
-        Specifies a source data directory to synchronize the target with.
-        When <option>--source-pgdata</> is used, the source server must be
-        cleanly shut down.
+        Specifies path to the data directory of the source server, to
+        synchronize the target with. When <option>--source-pgdata</> is
+        used, the source server must be cleanly shut down.
        </para>
       </listitem>
      </varlistentry>
@@ -183,54 +183,54 @@ PostgreSQL documentation
  </refsect1>
 
  <refsect1>
-  <title>Theory of operation</title>
-
-  <para>
-   The basic idea is to copy everything from the new cluster to the old
-   cluster, except for the blocks that we know to be the same.
-  </para>
-
-  <procedure>
-   <step>
-    <para>
-     Scan the WAL log of the old cluster, starting from the last checkpoint
-     before the point where the new cluster's timeline history forked off
-     from the old cluster. For each WAL record, make a note of the data
-     blocks that were touched. This yields a list of all the data blocks
-     that were changed in the old cluster, after the new cluster forked off.
-    </para>
-   </step>
-   <step>
-    <para>
-     Copy all those changed blocks from the new cluster to the old cluster.
-    </para>
-   </step>
-   <step>
-    <para>
-     Copy all other files like clog, conf files etc. from the new cluster
-     to old cluster. Everything except the relation files.
-    </para>
-   </step>
-   <step>
-    <para>
-     Apply the WAL from the new cluster, starting from the checkpoint
-     created at failover. (Strictly speaking, <application>pg_rewind</>
-     doesn't apply the WAL, it just creates a backup label file indicating
-     that when <productname>PostgreSQL</> is started, it will start replay
-     from that checkpoint and apply all the required WAL.)
-    </para>
-   </step>
-  </procedure>
- </refsect1>
-
- <refsect1>
-  <title>Restrictions</title>
+  <title>Notes</title>
 
   <para>
    <application>pg_rewind</> requires that the <varname>wal_log_hints</>
    option is enabled in <filename>postgresql.conf</>, or that data checksums
    were enabled when the cluster was initialized with <application>initdb</>.
   </para>
+
+  <refsect2>
+   <title>How it works</title>
+
+   <para>
+    The basic idea is to copy everything from the new cluster to the old
+    cluster, except for the blocks that we know to be the same.
+   </para>
+
+   <procedure>
+    <step>
+     <para>
+      Scan the WAL log of the old cluster, starting from the last checkpoint
+      before the point where the new cluster's timeline history forked off
+      from the old cluster. For each WAL record, make a note of the data
+      blocks that were touched. This yields a list of all the data blocks
+      that were changed in the old cluster, after the new cluster forked off.
+     </para>
+    </step>
+    <step>
+     <para>
+      Copy all those changed blocks from the new cluster to the old cluster.
+     </para>
+    </step>
+    <step>
+     <para>
+      Copy all other files like clog, conf files etc. from the new cluster
+      to old cluster. Everything except the relation files.
+     </para>
+    </step>
+    <step>
+     <para>
+      Apply the WAL from the new cluster, starting from the checkpoint
+      created at failover. (Strictly speaking, <application>pg_rewind</>
+      doesn't apply the WAL, it just creates a backup label file indicating
+      that when <productname>PostgreSQL</> is started, it will start replay
+     from that checkpoint and apply all the required WAL.)
+     </para>
+    </step>
+   </procedure>
+  </refsect2>
  </refsect1>
 
 </refentry>
-- 
2.39.5