Re: BUG #16497: old and new pg_controldata WAL segment sizes are invalid or do not match

On Thu, Jun 18, 2020 at 12:14:25PM -0400, Jeff Janes wrote:
> On Thu, Jun 18, 2020 at 11:16 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> > Since wal-segsize is changeable with pg_resetwal since v11, and
> pg_upgrade
> > is already calling pg_resetwal, shouldn't pg_upgrade ideally just deal
> with
> > this situation automatically by allowing the upgrade to also change this
> > value, rather than forcing the user to make them match manually?
>
> The issue is that this is an initdb parameter, and pg_upgrade expects you
> to have already initdb'd the destination cluster.  We could redefine that,
> perhaps, but it'd be a large change in how one uses pg_upgrade and would
> certainly break a lot of scripts.
>
> I'm aware that we could use pg_resetwal to deal with this one specific
> initdb parameter, but I see no point in hacking around the problem for
> just one parameter.  The general principle remains that you need to
> initdb the target with the same settings you used for the source.
>
>
> Since you mention it, now that -B is not necessary (inferred from where
> pg_upgrade itself is found), I have certainly thought it would also be nice if
> -D could point to a non-existent or empty directory, and have it do the initdb
> for you.  It would be nice to have it figure out the correct settings of -E,
> -U, --lc-collate, --lc-ctype and whatever else is needed to make --check pass,
> rather than doing it all manually (and one at a time, since it stops at the
> first error).  It doesn't seem like this, or the previously described change,
> would break any scripts which currently work.  It might cause some currently
> broken ones to work in ways that are unexpected, though.

Yes, it would be nice, but there is also the requirement of adjusting
postgresql.conf to match the old cluster. I am not sure we can get away
without that step, but looking at how people automate pg_upgrade would
help determine that.

Basically, if pg_upgrade ran initdb, we would need to automate steps 5-8
here:

https://www.postgresql.org/docs/12/pgupgrade.html

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee