Hi,
> Hi,
>
> This patch adds an --initdb option to pg_upgrade that automates the initdb step currently required before running
pg_upgrade.
>
> Problem
> —————
> Before running pg_upgrade, users must manually run initdb with options that exactly match the old cluster: WAL
segmentsize, data checksum setting, encoding, and locale. Getting these right is error-prone. A mismatch results in a
confusingcheck_control_data() failure after the user has already invested time in setting up the new cluster. A related
questionwas raised before [1], where Jeff Davis discussed whether pg_upgrade should perform initdb itself rather than
requiringa pre-initialized cluster.
>
> Solution
> ————
> With --initdb, pg_upgrade handles this automatically. It derives the WAL segment size and checksum setting from
pg_controland invokes initdb with the correct flags. The option refuses to proceed if the new cluster already exists.
>
Thanks for the patch but I have a couple of concerns that will require
further discussion.
Since we include the initdb option to pg_upgrade it can cause orphan
directories that users must manually solve. Partial initdb failures
leave orphaned clusters.
Moreover, in the patch the old cluster is being started/stopped twice
meaning that the pg_upgrade needs to manage the states. This will
cause unpredictable behavior on retry and make things really hard to
debug I believe.
On the other side, the responsibility of pg_upgrade shouldn't contain
initializing a new cluster and deciding the locale,encoding, and
checksums. If the idea is accepted we should focus on documentation
and avoid the risks it will introduce during the upgrade.
Regards,
Demir.
