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

From: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
To: Hüseyin Demir <huseyin(dot)d3r(at)gmail(dot)com>
Cc: Bohyun Lee <bohyun(dot)lee(at)databricks(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] pg_upgrade: add --initdb option to create the new cluster automatically
Date: 2026-08-13 14:45:42
Message-ID: CAKAnmmLskGy4GUbogLuoywLfhnq=khNdACj5NpvpLEaed-yQUw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 12, 2026 at 9:28 AM Hüseyin Demir <huseyin(dot)d3r(at)gmail(dot)com> wrote:

> When I run the pg_upgrade command with the following options I'd
> expect it to not create a directory and initdb.
>
> ```
> pg_upgrade --check --initdb -d /old -D /new
> ```
>

I see your point. Maybe we don't allow --check with --initdb at all?

also mention that -B flag points outs to target version correctly
> since there is a risk of doing an initdb with the wrong version. If -B
> points to an older version, pg_upgrade may create the wrong cluster.
>

I'm not clear what pointing this out for --initdb only accomplishes. A
wrong -B is going to cause problems regardless of the mode.

And the --initdb behaviour will introduce additional risks during the
> upgrade. During the initdb the settings discovery connections are
> allowed on database level and we don't have a guarantee that
> checkpoint and vacuums won't start. This needs to be documented
> clearly or we should consider eliminating them.
>

Eliminating what exactly? And why would a vacuum or checkpoint cause
problems?

Cheers,
Greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marcos Pegoraro 2026-08-13 14:50:40 Re: Correct some doc items due to the REPACK
Previous Message Pierre Forstmann 2026-08-13 14:23:29 Re: [PATCH] Add planner support function to two-argument regexp_like()