| 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
| 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() |