Re: pg_upgrade documentation improvement patch - Mailing list pgsql-hackers

From Yuri Niyazov
Subject Re: pg_upgrade documentation improvement patch
Date
Msg-id CACuBw0jqzzOnAV=OKvMorfm=B2Jx3sRsB4YLR3-7xL9zu0AamQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade documentation improvement patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_upgrade documentation improvement patch  (Michael Paquier <michael.paquier@gmail.com>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Postgres 9.6 scariest patch tournament
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_upgrade documentation improvement patch