mirror of
https://github.com/postgres/postgres.git
synced 2025-07-28 23:42:10 +03:00
pg_upgrade: Add --set-char-signedness to set the default char signedness of new cluster.
This change adds a new option --set-char-signedness to pg_upgrade. It enables user to set arbitrary signedness during pg_upgrade. This helps cases where user who knew they copied the v17 source cluster from x86 (signedness=true) to ARM (signedness=false) can pg_upgrade properly without the prerequisite of acquiring an x86 VM. Reviewed-by: Noah Misch <noah@leadboat.com> Discussion: https://postgr.es/m/CB11ADBC-0C3F-4FE0-A678-666EE80CBB07%40amazon.com
This commit is contained in:
@ -285,6 +285,59 @@ PostgreSQL documentation
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--set-char-signedness=</option><replaceable>option</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Manually set the default char signedness of new clusters. Possible values
|
||||
are <literal>signed</literal> and <literal>unsigned</literal>.
|
||||
</para>
|
||||
<para>
|
||||
In the C language, the default signedness of the <type>char</type> type
|
||||
(when not explicitly specified) varies across platforms. For example,
|
||||
<type>char</type> defaults to <type>signed char</type> on x86 CPUs but
|
||||
to <type>unsigned char</type> on ARM CPUs.
|
||||
</para>
|
||||
<para>
|
||||
Starting from <productname>PostgreSQL</productname> 18, database clusters
|
||||
maintain their own default char signedness setting, which can be used to
|
||||
ensure consistent behavior across platforms with different default char
|
||||
signedness. By default, <application>pg_upgrade</application> preserves
|
||||
the char signedness setting when upgrading from an existing cluster.
|
||||
However, when upgrading from <productname>PostgreSQL</productname> 17 or
|
||||
earlier, <application>pg_upgrade</application> adopts the char signedness
|
||||
of the platform on which it was built.
|
||||
</para>
|
||||
<para>
|
||||
This option allows you to explicitly set the default char signedness for
|
||||
the new cluster, overriding any inherited values. There are two specific
|
||||
scenarios where this option is relevant:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
If you are planning to migrate to a different platform after the upgrade,
|
||||
you should not use this option. The default behavior is right in this case.
|
||||
Instead, perform the upgrade on the original platform without this flag,
|
||||
and then migrate the cluster afterward. This is the recommended and safest
|
||||
approach.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If you have already migrated the cluster to a platform with different
|
||||
char signedness (for example, from an x86-based system to an ARM-based
|
||||
system), you should use this option to specify the signedness matching
|
||||
the original platform's default char signedness. Additionally, it's
|
||||
essential not to modify any data files between migrating data files and
|
||||
running <command>pg_upgrade</command>. <command>pg_upgrade</command>
|
||||
should be the first operation that starts the cluster on the new platform.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-?</option></term>
|
||||
<term><option>--help</option></term>
|
||||
|
Reference in New Issue
Block a user