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

From Alvaro Herrera
Subject Re: pg_upgrade documentation improvement patch
Date
Msg-id 20160418185728.GA613319@alvherre.pgsql
Whole thread Raw
In response to Re: pg_upgrade documentation improvement patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane 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.

Agreed.  It's always seemed to me that having pg_upgrade require you to
run initdb is unfriendly; it seems so much more convenient to have it do
the initdb etc for you, where you just specify the target directory
(probably created ahead of time because of ownership -- but initdb
already knows how to deal with that case).

Also, pg_upgrade receiving a pre-existing cluster is inconvenient
because it needs to verify that it's empty etc, for no good reason.

> 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.

I don't think we've ever had a backwards-incompatible change in
pg_hba.conf (so we could just copy it over verbatim), and the
postgresql.conf changes should be mostly easy to deal with (so we could
just copy it over and modify a small number of lines), but I wonder if
things like nonstandard locations of config files might be problematic.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Yuri Niyazov
Date:
Subject: Re: pg_upgrade documentation improvement patch
Next
From: Stephen Frost
Date:
Subject: Re: SET ROLE and reserved roles