Commit 5efbdd36 authored by Peter Eisentraut's avatar Peter Eisentraut

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

parent 3b9b7516
......@@ -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>
......
......@@ -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>
......
......@@ -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>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment