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 по дате отправления: