Skip to content

Commit bc35ade

Browse files
peterepetere
committed
doc: Put new options in consistent order on man pages
1 parent b28c59a commit bc35ade

File tree

5 files changed

+294
-294
lines changed

5 files changed

+294
-294
lines changed

‎doc/src/sgml/ref/pg_combinebackup.sgml

Lines changed: 29 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -81,6 +81,35 @@ PostgreSQL documentation
8181
</listitem>
8282
</varlistentry>
8383

84+
<varlistentry>
85+
<term><option>-k</option></term>
86+
<term><option>--link</option></term>
87+
<listitem>
88+
<para>
89+
Use hard links instead of copying files to the synthetic backup.
90+
Reconstruction of the synthetic backup might be faster (no file copying)
91+
and use less disk space, but care must be taken when using the output
92+
directory, because any modifications to that directory (for example,
93+
starting the server) can also affect the input directories. Likewise,
94+
changes to the input directories (for example, starting the server on
95+
the full backup) could affect the output directory. Thus, this option
96+
is best used when the input directories are only copies that will be
97+
removed after <application>pg_combinebackup</application> has completed.
98+
</para>
99+
100+
<para>
101+
Requires that the input backups and the output directory are in the
102+
same file system.
103+
</para>
104+
105+
<para>
106+
If a backup manifest is not available or does not contain checksum of
107+
the right type, hard links will still be created, but the file will be
108+
also read block-by-block for the checksum calculation.
109+
</para>
110+
</listitem>
111+
</varlistentry>
112+
84113
<varlistentry>
85114
<term><option>-n</option></term>
86115
<term><option>--dry-run</option></term>
@@ -137,35 +166,6 @@ PostgreSQL documentation
137166
</listitem>
138167
</varlistentry>
139168

140-
<varlistentry>
141-
<term><option>-k</option></term>
142-
<term><option>--link</option></term>
143-
<listitem>
144-
<para>
145-
Use hard links instead of copying files to the synthetic backup.
146-
Reconstruction of the synthetic backup might be faster (no file copying)
147-
and use less disk space, but care must be taken when using the output
148-
directory, because any modifications to that directory (for example,
149-
starting the server) can also affect the input directories. Likewise,
150-
changes to the input directories (for example, starting the server on
151-
the full backup) could affect the output directory. Thus, this option
152-
is best used when the input directories are only copies that will be
153-
removed after <application>pg_combinebackup</application> has completed.
154-
</para>
155-
156-
<para>
157-
Requires that the input backups and the output directory are in the
158-
same file system.
159-
</para>
160-
161-
<para>
162-
If a backup manifest is not available or does not contain checksum of
163-
the right type, hard links will still be created, but the file will be
164-
also read block-by-block for the checksum calculation.
165-
</para>
166-
</listitem>
167-
</varlistentry>
168-
169169
<varlistentry>
170170
<term><option>--clone</option></term>
171171
<listitem>

‎doc/src/sgml/ref/pg_resetwal.sgml

Lines changed: 47 additions & 47 deletions
Original file line numberDiff line numberDiff line change
@@ -171,25 +171,6 @@ PostgreSQL documentation
171171
</para>
172172

173173
<variablelist>
174-
<varlistentry>
175-
<term><option>--char-signedness=<replaceable class="parameter">option</replaceable></option></term>
176-
<listitem>
177-
<para>
178-
Manually set the default char signedness. Possible values are
179-
<literal>signed</literal> and <literal>unsigned</literal>.
180-
</para>
181-
<para>
182-
For a database cluster that <command>pg_upgrade</command> upgraded from
183-
a <productname>PostgreSQL</productname> version before 18, the safe
184-
value would be the default <type>char</type> signedness of the platform
185-
that ran the cluster before that upgrade. For all other
186-
clusters, <literal>signed</literal> would be the safe value. However,
187-
this option is exclusively for use with <command>pg_upgrade</command>
188-
and should not normally be used manually.
189-
</para>
190-
</listitem>
191-
</varlistentry>
192-
193174
<varlistentry>
194175
<term><option>-c <replaceable class="parameter">xid</replaceable>,<replaceable class="parameter">xid</replaceable></option></term>
195176
<term><option>--commit-timestamp-ids=<replaceable class="parameter">xid</replaceable>,<replaceable class="parameter">xid</replaceable></option></term>
@@ -332,34 +313,6 @@ PostgreSQL documentation
332313
</listitem>
333314
</varlistentry>
334315

335-
<varlistentry>
336-
<term><option>--wal-segsize=<replaceable class="parameter">wal_segment_size</replaceable></option></term>
337-
<listitem>
338-
<para>
339-
Set the new WAL segment size, in megabytes. The value must be set to a
340-
power of 2 between 1 and 1024 (megabytes). See the same option of <xref
341-
linkend="app-initdb"/> for more information.
342-
</para>
343-
344-
<para>
345-
This option can also be used to change the WAL segment size of an
346-
existing database cluster, avoiding the need to
347-
re-<command>initdb</command>.
348-
</para>
349-
350-
<note>
351-
<para>
352-
While <command>pg_resetwal</command> will set the WAL starting address
353-
beyond the latest existing WAL segment file, some segment size changes
354-
can cause previous WAL file names to be reused. It is recommended to
355-
use <option>-l</option> together with this option to manually set the
356-
WAL starting address if WAL file name overlap will cause problems with
357-
your archiving strategy.
358-
</para>
359-
</note>
360-
</listitem>
361-
</varlistentry>
362-
363316
<varlistentry>
364317
<term><option>-u <replaceable class="parameter">xid</replaceable></option></term>
365318
<term><option>--oldest-transaction-id=<replaceable class="parameter">xid</replaceable></option></term>
@@ -402,6 +355,53 @@ PostgreSQL documentation
402355
<!-- 1048576 = SLRU_PAGES_PER_SEGMENT * BLCKSZ * CLOG_XACTS_PER_BYTE -->
403356
</listitem>
404357
</varlistentry>
358+
359+
<varlistentry>
360+
<term><option>--char-signedness=<replaceable class="parameter">option</replaceable></option></term>
361+
<listitem>
362+
<para>
363+
Manually set the default char signedness. Possible values are
364+
<literal>signed</literal> and <literal>unsigned</literal>.
365+
</para>
366+
<para>
367+
For a database cluster that <command>pg_upgrade</command> upgraded from
368+
a <productname>PostgreSQL</productname> version before 18, the safe
369+
value would be the default <type>char</type> signedness of the platform
370+
that ran the cluster before that upgrade. For all other
371+
clusters, <literal>signed</literal> would be the safe value. However,
372+
this option is exclusively for use with <command>pg_upgrade</command>
373+
and should not normally be used manually.
374+
</para>
375+
</listitem>
376+
</varlistentry>
377+
378+
<varlistentry>
379+
<term><option>--wal-segsize=<replaceable class="parameter">wal_segment_size</replaceable></option></term>
380+
<listitem>
381+
<para>
382+
Set the new WAL segment size, in megabytes. The value must be set to a
383+
power of 2 between 1 and 1024 (megabytes). See the same option of <xref
384+
linkend="app-initdb"/> for more information.
385+
</para>
386+
387+
<para>
388+
This option can also be used to change the WAL segment size of an
389+
existing database cluster, avoiding the need to
390+
re-<command>initdb</command>.
391+
</para>
392+
393+
<note>
394+
<para>
395+
While <command>pg_resetwal</command> will set the WAL starting address
396+
beyond the latest existing WAL segment file, some segment size changes
397+
can cause previous WAL file names to be reused. It is recommended to
398+
use <option>-l</option> together with this option to manually set the
399+
WAL starting address if WAL file name overlap will cause problems with
400+
your archiving strategy.
401+
</para>
402+
</note>
403+
</listitem>
404+
</varlistentry>
405405
</variablelist>
406406
</refsect1>
407407

0 commit comments

Comments
 (0)