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

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Bohyun Lee <bohyun(dot)lee(at)databricks(dot)com>
Cc: Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] pg_upgrade: add --initdb option to create the new cluster automatically
Date: 2026-07-16 14:29:13
Message-ID: 5C80002C-27DA-4861-B20D-23DA28817CF5@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 14 Jul 2026, at 16:42, Bohyun Lee <bohyun(dot)lee(at)databricks(dot)com> wrote:

Thanks for the update.

Right now most of the focus is on getting v19 ready to ship, I recommend
registering the patch in the commitfest app to make sure it's not lost (if you
already did I just failed to find it).

> On external wrapper vs. in-tree: the point of --initdb is deriving the new cluster's settings (WAL segment size, checksums, encoding, locale) from the old cluster, exactly what people get wrong by hand and only discover when check_control_data() fails. pg_upgrade already reads the old control data, so doing it here reuses that rather than making a wrapper rediscover it. I'm open to being convinced otherwise.

Maybe. Since it won't be a mandatory step, we still need to document the
process properly and I see that as the first step. Currently the docs have
"use compatible initdb flags that match the old cluster" which clearly isn't
particularly helpful.

--
Daniel Gustafsson

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2026-07-16 14:32:46 Re: Allow table AMs to define their own reloptions
Previous Message Zsolt Parragi 2026-07-16 14:28:14 Re: pg_hosts: Add pg_hosts_file_rules()