Re: [PATCH] pg_upgrade: add --initdb option to create the new cluster automatically

On 07/10/2026 20:44, Bohyun Lee wrote:
> *2. Group access — Shihao #2*
> > The group access setting from initdb -g is not copied from the old
> > cluster.
>
> The current patch now preserves the old cluster's group-access setting
> by passing --allow-group-access to initdb when the old cluster allows
> group access.

I don't think we should do this. If the user wants the new cluster to
have group access, use --initdb-options='--allow-group-access'. There's
no magic for that before this patch either, the user needs to use
"initdb --allow_group_access" if they want the new cluster to have group
access.

The user could've made other changes to the permissions too, like change
the group that owns the data dir etc. If we tried to accurately copy all
the old permissions, that seems like an endless task.

> *4. Log location and cleanup — Shihao #4*
> > The <pgdata>.initdb_log directory is never deleted.  It stays after a
> > successful run and after --check, and --retain has no effect on it.
>
> The patch is updated so that it now writes --initdb logs under ./
> pg_upgrade_output.d
> in the current working directory, using the normal cleanup and --retain
> handling. Successful runs, including --check, remove their logs unless
> --retain is given; failed runs keep them.

Why not write the logs under the new data directory, just like without
--initdb?

> This avoids requiring write access to the new data directory's parent
> just for logging. Logs stay outside the new data directory because
> initdb requires it to be empty.

But then you need write access to the current directory instead.

> Heikki Linnakangas wrote:
>
> > That's not good, that essentially means that --check doesn't work with
> > the --initdb option. Some of the checks check that the new cluster is
> > compatible with the old cluster, and assuming we run initdb correctly,
> > there's no need to run those checks with --initdb. But we should still
> > run all the checks we can on the old cluster.
>
> The current patch now allows --check --initdb to check a running old
> server without stopping it.

Ok

> The new server must use a different port.

Why?

> Additionally, the patch now initializes the new cluster and runs the
> compatibility checks on both clusters for --check --initdb, without
> performing the upgrade. Unsupported regproc columns cause the check to
> fail.

There should be no need to perform checks on the new cluster. We're
creating it, so it should be created with all the right settings.

Hmm, although I guess a user-supplied --initdb-options could contain
bogus options, or options that make the new cluster incompatible in some
way. Ok, I guess it's good to check for that somehow.

> --check --initdb retains the initialized new cluster whether the
> compatibility
> checks succeed or fail. After a successful check, rerun pg_upgrade
> against that
> cluster without --check, --initdb, or --initdb-options.

Does that mean that if you run "pg_upgrade .. --check --initdb" twice,
it will fail the second time because the new cluster already exists?
That doesn't sound nice.

> *9. Passing extra options to initdb — Heikki*
> > 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?
>
> The current patch now provides --initdb-options to pass additional
> arguments to initdb, for example:
>
> pg_upgrade --initdb \
>   --initdb-options='-c huge_pages=off --waldir=/wal/new' ...
>
> It requires --initdb and it can be repeated, preserving upstream initdb
> option
> ordering.

Ok.

> Settings passed with initdb -c apply during initialization and remain in
> postgresql.conf. Options that conflict with pg_upgrade's managed
> settings are
> rejected, while other option values and paths are validated by initdb.

The code for those compatibility checks seem overly complicated. We
shouldn't need to duplicate all the initdb options in pg_upgrade just
for this. What if we just didn't do any of that validation and passed
the initdb options directly to initdb, and let initdb fail if they're
incorrect?

If we must have some cross-checking like this, then I'd suggest adding a
hidden "initdb --for-pg-upgrade" option or something, to let initdb know
that it's been called as part of pg_ugprade, and have initdb itself
reject the options that are not allowed with pg_upgrade. Seems like less
duplication that way. But please see if we can get away without any
validation like this first.

- Heikki