</listitem>

</varlistentry>

<varlistentry>

<term><option>-k</option></term>

<term><option>--link</option></term>

<listitem>

<para>

Use hard links instead of copying files to the synthetic backup.

Reconstruction of the synthetic backup might be faster (no file copying)

and use less disk space, but care must be taken when using the output

directory, because any modifications to that directory (for example,

starting the server) can also affect the input directories. Likewise,

changes to the input directories (for example, starting the server on

the full backup) could affect the output directory. Thus, this option

is best used when the input directories are only copies that will be

removed after <application>pg_combinebackup</application> has completed.

</para>

<para>

Requires that the input backups and the output directory are in the

same file system.

</para>

<para>

If a backup manifest is not available or does not contain checksum of

the right type, hard links will still be created, but the file will be

also read block-by-block for the checksum calculation.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><option>-n</option></term>

<term><option>--dry-run</option></term>

</listitem>

</varlistentry>

<varlistentry>

<term><option>-k</option></term>

<term><option>--link</option></term>

<listitem>

<para>

Use hard links instead of copying files to the synthetic backup.

Reconstruction of the synthetic backup might be faster (no file copying)

and use less disk space, but care must be taken when using the output

directory, because any modifications to that directory (for example,

starting the server) can also affect the input directories. Likewise,

changes to the input directories (for example, starting the server on

the full backup) could affect the output directory. Thus, this option

is best used when the input directories are only copies that will be

removed after <application>pg_combinebackup</application> has completed.

</para>

<para>

Requires that the input backups and the output directory are in the

same file system.

</para>

<para>

If a backup manifest is not available or does not contain checksum of

the right type, hard links will still be created, but the file will be

also read block-by-block for the checksum calculation.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><option>--clone</option></term>

<listitem>

</para>

<variablelist>

<varlistentry>

<term><option>--char-signedness=<replaceable class="parameter">option</replaceable></option></term>

<listitem>

<para>

Manually set the default char signedness. Possible values are

<literal>signed</literal> and <literal>unsigned</literal>.

</para>

<para>

For a database cluster that <command>pg_upgrade</command> upgraded from

a <productname>PostgreSQL</productname> version before 18, the safe

value would be the default <type>char</type> signedness of the platform

that ran the cluster before that upgrade. For all other

clusters, <literal>signed</literal> would be the safe value. However,

this option is exclusively for use with <command>pg_upgrade</command>

and should not normally be used manually.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><option>-c <replaceable class="parameter">xid</replaceable>,<replaceable class="parameter">xid</replaceable></option></term>

<term><option>--commit-timestamp-ids=<replaceable class="parameter">xid</replaceable>,<replaceable class="parameter">xid</replaceable></option></term>

</listitem>

</varlistentry>

<varlistentry>

<term><option>--wal-segsize=<replaceable class="parameter">wal_segment_size</replaceable></option></term>

<listitem>

<para>

Set the new WAL segment size, in megabytes. The value must be set to a

power of 2 between 1 and 1024 (megabytes). See the same option of <xref

linkend="app-initdb"/> for more information.

</para>

<para>

This option can also be used to change the WAL segment size of an

existing database cluster, avoiding the need to

re-<command>initdb</command>.

</para>

<note>

<para>

While <command>pg_resetwal</command> will set the WAL starting address

beyond the latest existing WAL segment file, some segment size changes

can cause previous WAL file names to be reused. It is recommended to

use <option>-l</option> together with this option to manually set the

WAL starting address if WAL file name overlap will cause problems with

your archiving strategy.

</para>

</note>

</listitem>

</varlistentry>

<varlistentry>

<term><option>-u <replaceable class="parameter">xid</replaceable></option></term>

<term><option>--oldest-transaction-id=<replaceable class="parameter">xid</replaceable></option></term>

<!-- 1048576 = SLRU_PAGES_PER_SEGMENT * BLCKSZ * CLOG_XACTS_PER_BYTE -->

</listitem>

</varlistentry>

<varlistentry>

<term><option>--char-signedness=<replaceable class="parameter">option</replaceable></option></term>

<listitem>

<para>

Manually set the default char signedness. Possible values are

<literal>signed</literal> and <literal>unsigned</literal>.

</para>

<para>

For a database cluster that <command>pg_upgrade</command> upgraded from

a <productname>PostgreSQL</productname> version before 18, the safe

value would be the default <type>char</type> signedness of the platform

that ran the cluster before that upgrade. For all other

clusters, <literal>signed</literal> would be the safe value. However,

this option is exclusively for use with <command>pg_upgrade</command>

and should not normally be used manually.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><option>--wal-segsize=<replaceable class="parameter">wal_segment_size</replaceable></option></term>

<listitem>

<para>

Set the new WAL segment size, in megabytes. The value must be set to a

power of 2 between 1 and 1024 (megabytes). See the same option of <xref

linkend="app-initdb"/> for more information.

</para>

<para>

This option can also be used to change the WAL segment size of an

existing database cluster, avoiding the need to

re-<command>initdb</command>.

</para>

<note>

<para>

While <command>pg_resetwal</command> will set the WAL starting address

beyond the latest existing WAL segment file, some segment size changes

can cause previous WAL file names to be reused. It is recommended to

use <option>-l</option> together with this option to manually set the

WAL starting address if WAL file name overlap will cause problems with

your archiving strategy.

</para>

</note>

</listitem>

</varlistentry>

</variablelist>

</refsect1>