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 segment size, data checksum setting, > encoding, and locale. Getting these right is error-prone. A mismatch results > in a confusing check_control_data() failure after the user has already > invested time in setting up the new cluster. A related question was raised > before [1], where Jeff Davis discussed whether pg_upgrade should perform > initdb itself rather than requiring a pre-initialized cluster. > > Solution > ———— > With --initdb, pg_upgrade handles this automatically. It derives the WAL > segment size and checksum setting from pg_control and 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.
