Re: A Modest Upgrade Proposal
От | Bruce Momjian |
---|---|
Тема | Re: A Modest Upgrade Proposal |
Дата | |
Msg-id | 20160727203506.GG27321@momjian.us обсуждение исходный текст |
Ответ на | Re: A Modest Upgrade Proposal (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: A Modest Upgrade Proposal
|
Список | pgsql-hackers |
On Fri, Jul 8, 2016 at 12:18:28AM +0100, Simon Riggs wrote: > On 7 July 2016 at 21:10, Robert Haas <robertmhaas@gmail.com> wrote: > > pg_upgrade does that, kinda. I'd like to have something better, but > in the absence of that, I think it's quite wrong to think about > deprecating it, even if we had logical replication fully integrated > into core today. Which we by no means do. > > I don't see any problem with extending pg_upgrade to use logical replication > features under the covers. > > It seems very smooth to be able to just say > > pg_upgrade --online > > and then specify whatever other parameters that requires. > > It would be much easier to separate out that as a use-case so we can be sure we > get that in 10.0, even if nothing else lands. Uh, while "pg_upgrade --online" looks cool, I am not sure a solution based on logical replication would share _any_ code with the existing pg_upgrade tool, so it seems best to use another binary for this. I guess we could use the pg_dump/pg_restore pg_upgrade code to create the objects, and use logical replication to copy the rows, but what does this gain us that pg_dump/pg_restore doesn't? Wouldn't you just create the standby using logical replication and just switch-over? Why use pg_upgrade at all? Am I missing something? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления: