]> granicus.if.org Git - postgresql/commitdiff
doc: Move some new options into better positions on man pages
authorPeter Eisentraut <peter_e@gmx.net>
Fri, 8 Jun 2018 03:36:04 +0000 (23:36 -0400)
committerPeter Eisentraut <peter_e@gmx.net>
Fri, 8 Jun 2018 03:36:04 +0000 (23:36 -0400)
doc/src/sgml/ref/initdb.sgml
doc/src/sgml/ref/pg_dump.sgml
doc/src/sgml/ref/pg_dumpall.sgml

index feefd9a41e037b1a57c7beddd611c7f1ee6bb221..4489b585c7ad87b27bda5bdd2a093161cbb2bed2 100644 (file)
@@ -334,27 +334,6 @@ PostgreSQL documentation
       </listitem>
      </varlistentry>
 
-     <varlistentry>
-       <term><option>--wal-segsize=<replaceable>size</replaceable></option></term>
-       <listitem>
-        <para>
-         Set the <firstterm>WAL segment size</firstterm>, in megabytes.  This
-         is the size of each individual file in the WAL log.  The default size
-         is 16 megabytes.  The value must be a power of 2 between 1 and 1024
-         (megabytes).  This option can only be set during initialization, and
-         cannot be changed later.
-        </para>
-
-        <para>
-         It may be useful to adjust this size to control the granularity of
-         WAL log shipping or archiving.  Also, in databases with a high volume
-         of WAL, the sheer number of WAL files per directory can become a
-         performance and management problem.  Increasing the WAL file size
-         will reduce the number of WAL files.
-        </para>
-       </listitem>
-      </varlistentry>
-
       <varlistentry>
       <term><option>-X <replaceable class="parameter">directory</replaceable></option></term>
       <term><option>--waldir=<replaceable class="parameter">directory</replaceable></option></term>
@@ -366,6 +345,26 @@ PostgreSQL documentation
       </listitem>
      </varlistentry>
 
+     <varlistentry>
+      <term><option>--wal-segsize=<replaceable>size</replaceable></option></term>
+      <listitem>
+       <para>
+        Set the <firstterm>WAL segment size</firstterm>, in megabytes.  This
+        is the size of each individual file in the WAL log.  The default size
+        is 16 megabytes.  The value must be a power of 2 between 1 and 1024
+        (megabytes).  This option can only be set during initialization, and
+        cannot be changed later.
+       </para>
+
+       <para>
+        It may be useful to adjust this size to control the granularity of
+        WAL log shipping or archiving.  Also, in databases with a high volume
+        of WAL, the sheer number of WAL files per directory can become a
+        performance and management problem.  Increasing the WAL file size
+        will reduce the number of WAL files.
+       </para>
+      </listitem>
+     </varlistentry>
     </variablelist>
    </para>
 
index 64ced9fe045b46fb4f0deee57414a610612bf2d3..f402d46b0cfbd74818f0dc7a1ecaf39d04bd77a7 100644 (file)
@@ -789,21 +789,6 @@ PostgreSQL documentation
       </listitem>
      </varlistentry>
 
-     <varlistentry>
-      <term><option>--lock-wait-timeout=<replaceable class="parameter">timeout</replaceable></option></term>
-      <listitem>
-       <para>
-        Do not wait forever to acquire shared table locks at the beginning of
-        the dump. Instead fail if unable to lock a table within the specified
-        <replaceable class="parameter">timeout</replaceable>. The timeout may be
-        specified in any of the formats accepted by <command>SET
-        statement_timeout</command>.  (Allowed formats vary depending on the server
-        version you are dumping from, but an integer number of milliseconds
-        is accepted by all versions.)
-       </para>
-      </listitem>
-     </varlistentry>
-
      <varlistentry>
       <term><option>--load-via-partition-root</option></term>
       <listitem>
@@ -819,6 +804,21 @@ PostgreSQL documentation
       </listitem>
      </varlistentry>
 
+     <varlistentry>
+      <term><option>--lock-wait-timeout=<replaceable class="parameter">timeout</replaceable></option></term>
+      <listitem>
+       <para>
+        Do not wait forever to acquire shared table locks at the beginning of
+        the dump. Instead fail if unable to lock a table within the specified
+        <replaceable class="parameter">timeout</replaceable>. The timeout may be
+        specified in any of the formats accepted by <command>SET
+        statement_timeout</command>.  (Allowed formats vary depending on the server
+        version you are dumping from, but an integer number of milliseconds
+        is accepted by all versions.)
+       </para>
+      </listitem>
+     </varlistentry>
+
      <varlistentry>
       <term><option>--no-comments</option></term>
       <listitem>
index 8e5e7f9ef8a67265df632c9d6c516ee9f8faff04..22cb7907035ad1dbd1d96f34e54912e9521f01f7 100644 (file)
@@ -326,6 +326,21 @@ PostgreSQL documentation
       </listitem>
      </varlistentry>
 
+     <varlistentry>
+      <term><option>--load-via-partition-root</option></term>
+      <listitem>
+       <para>
+        When dumping a <command>COPY</command> or <command>INSERT</command> statement for a partitioned table,
+        target the root of the partitioning hierarchy which contains it rather
+        than the partition itself.  This may be useful when reloading data on
+        a server where rows do not always fall into the same partitions as
+        they did on the original server.  This could happen, for example, if
+        the partitioning column is of type text and the two system have
+        different definitions of the collation used to partition the data.
+       </para>
+      </listitem>
+     </varlistentry>
+
      <varlistentry>
       <term><option>--lock-wait-timeout=<replaceable class="parameter">timeout</replaceable></option></term>
       <listitem>
@@ -342,21 +357,6 @@ PostgreSQL documentation
       </listitem>
      </varlistentry>
 
-     <varlistentry>
-      <term><option>--load-via-partition-root</option></term>
-      <listitem>
-       <para>
-        When dumping a <command>COPY</command> or <command>INSERT</command> statement for a partitioned table,
-        target the root of the partitioning hierarchy which contains it rather
-        than the partition itself.  This may be useful when reloading data on
-        a server where rows do not always fall into the same partitions as
-        they did on the original server.  This could happen, for example, if
-        the partitioning column is of type text and the two system have
-        different definitions of the collation used to partition the data.
-       </para>
-      </listitem>
-     </varlistentry>
-
      <varlistentry>
       <term><option>--no-comments</option></term>
       <listitem>