On 17/07/2026 15:10, Bohyun Lee wrote:
-O: dropped support with --initdb entirely, as you originally suggested. The partial "-c only" forwarding still broke on quoted values with spaces. pg_upgrade now rejects -O + --initdb during option parsing, with a test and a doc note.

@@ -244,6 +249,17 @@ parseCommandLine(int argc, char *argv[])
        if (optind < argc)
                pg_fatal("too many command-line arguments (first is \"%s\")", 
argv[optind]);
+ /*
+        * -O passes options to the new cluster's postmaster, but with --initdb
+        * the new cluster is created by initdb, which accepts a different 
option
+        * set.  Rather than guess which -O options initdb also understands, 
reject
+        * the combination and let the user create the cluster manually (without
+        * --initdb) if they need postmaster-only options.
+        */
+       if (new_cluster.pgopts && user_opts.initdb_new_cluster)
+               pg_fatal("options %s and %s cannot be used together",
+                                "-O/--new-options", "--initdb");
+
        if (!user_opts.sync_method)
                user_opts.sync_method = pg_strdup("fsync");

That doesn't sound right. There's indeed no reason think that initdb would accept the same options as postmaster, so it doesn't make sense to pass the -O options to initdb. But why forbid using -O with --initdb? I would imagine that the -O options are passed to the postmaster the same way with or without --initdb.

Is there a way to pass extra options to initdb? Or do you require the user to run initdb first or change the settings afterwards, if they want some additional settings?

+       <para>
+        To discover the old cluster's encoding and locale,
+        <option>--initdb</option> briefly starts the old server in
+        binary-upgrade mode (which disables autovacuum) and stops it again
+        before creating the new cluster.  If a compatibility check fails after
+        the new cluster has been created, its data directory is removed
+        automatically, so the upgrade can be retried without manual cleanup.
+       </para>

Hmm, how's that different from how it works without --initdb? pg_upgrade needs to launch the old cluster anyway to perform the compatibility checks, right?

- Heikki



Reply via email to