Tom Lane wrote:
> Peter Eisentraut <> 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      
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to