On Fri, Jul  8, 2016 at 12:18:28AM +0100, Simon Riggs wrote:
> On 7 July 2016 at 21:10, Robert Haas <robertmh...@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  <br...@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 +

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to