Re: pg_upgrade documentation improvement patch
От | Alvaro Herrera |
---|---|
Тема | Re: pg_upgrade documentation improvement patch |
Дата | |
Msg-id | 20160418185728.GA613319@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: pg_upgrade documentation improvement patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: