doc: Move some new options into better positions on man pages

This commit is contained in:
Peter Eisentraut 2018-06-07 23:36:04 -04:00
parent 3b9b7516f4
commit 5efbdd36f1
3 changed files with 50 additions and 51 deletions

View 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>

View 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>

View 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>