Re: pg_upgrade documentation improvement patch

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?

In response to

Responses

Browse pgsql-hackers by date

  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