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

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, ram(dot)maurya(at)lavainternational(dot)in, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16497: old and new pg_controldata WAL segment sizes are invalid or do not match
Date: 2020-06-18 16:14:25
Message-ID: CAMkU=1z3sW=kfQvv4gOXGvOOryxqziN4VqaEu7gH+qS8TTQ=1w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

Cheers,

Jeff

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2020-06-18 16:36:15 Re: BUG #16497: old and new pg_controldata WAL segment sizes are invalid or do not match
Previous Message Stephen Frost 2020-06-18 15:55:37 Re: BUG #16497: old and new pg_controldata WAL segment sizes are invalid or do not match