From: | Yuri Niyazov <yuri(at)academia(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_upgrade documentation improvement patch |
Date: | 2016-04-18 18:42:00 |
Message-ID: | CACuBw0jqzzOnAV=OKvMorfm=B2Jx3sRsB4YLR3-7xL9zu0AamQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 13, 2016 at 6:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-04-18 18:57:28 | Re: pg_upgrade documentation improvement patch |
Previous Message | Alvaro Herrera | 2016-04-18 18:37:21 | Postgres 9.6 scariest patch tournament |