Re: pg_upgrade documentation improvement patch

Поиск
Список
Период
Сортировка
От Yuri Niyazov
Тема Re: pg_upgrade documentation improvement patch
Дата
Msg-id CACuBw0jqzzOnAV=OKvMorfm=B2Jx3sRsB4YLR3-7xL9zu0AamQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_upgrade documentation improvement patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_upgrade documentation improvement patch  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Wed, Apr 13, 2016 at 6:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
> Interesting to me would be a way, perhaps with an option in initdb, to
> just say, initialize this cluster compatibly with that other cluster, so
> you don't have to worry about these details.

Good idea, though I'd think of it as a pg_upgrade option more than being
initdb's problem.  Either way, though, it would be on the code's head
to do something about converting the postgresql.conf, pg_hba.conf, etc
configuration files from the old cluster to the new, which means this
isn't just a trivial matter of running initdb on the target PGDATA
location.  That turns it into a bit of a research project I'm afraid
--- but if we could get there, it'd be a nice improvement.

                        regards, tom lane


There were other things that happened while doing this cluster upgrade that required more documentation searching - I believe some wal-related configuration options that go into postgresql.conf were deprecated in 9.5, so the server complained upon starting up - however, the documentation in that case was pretty clear about how to replace the old with the new. 

The phrase "Many prebuilt installers do this step automatically" - it was there originally, and I left it in, but I don't know any details about it. If this is true, then it seems to me that the work that goes into that can profitably go into pg_upgrade, no? 

From the point of view of a PG-admin noob like me, it's unclear *from the documentation* to what extent locale and encoding at the cluster level must match. Certainly the relatively stern phrase "Again, use compatible initdb flags that match the old cluster" in the documentation stopped me in my tracks until I got some further clarification, because the consequences of not doing so were not mentioned at all, and I lean towards conservatism when it comes to scary things like upgrading a production machine across a major version release. 

Should I update the documentation patch to instruct the use of pg_controldata exclusively?




 

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Postgres 9.6 scariest patch tournament
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_upgrade documentation improvement patch