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

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: BUG #16497: old and new pg_controldata WAL segment sizes areinvalid or do not match
Дата
Msg-id 20200618164048.GJ7349@momjian.us
обсуждение исходный текст
Ответ на Re: BUG #16497: old and new pg_controldata WAL segment sizes areinvalid or do not match  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-bugs
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@sss.pgh.pa.us> wrote:
> 
>     Jeff Janes <jeff.janes@gmail.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@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

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




В списке pgsql-bugs по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #16497: old and new pg_controldata WAL segment sizes areinvalid or do not match
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: BUG #16500: SQL Abend. selectmulti_key_columns_range_partition_table