Re: Speeding up pg_upgrade - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Speeding up pg_upgrade
Date
Msg-id 20171205142257.GC25023@momjian.us
Whole thread Raw
In response to Re: Speeding up pg_upgrade  (Dave Page <dpage@pgadmin.org>)
List pgsql-hackers
On Tue, Dec  5, 2017 at 11:16:26PM +0900, Dave Page wrote:
> Hi
> 
> On Tue, Dec 5, 2017 at 11:01 PM, Bruce Momjian <bruce@momjian.us> wrote:
> 
>     As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
>     zero-downtime upgrades.  After the usual discussion of using logical
>     replication, Slony, and perhaps having the server be able to read old
>     and new system catalogs, we discussed speeding up pg_upgrade.
> 
>     There are clusters that take a long time to dump the schema from the old
>     cluster and recreate it in the new cluster.  One idea of speeding up
>     pg_upgrade would be to allow pg_upgrade to be run in two stages:
> 
>     1.  prevent system catalog changes while the old cluster is running, and
>     dump the old cluster's schema and restore it in the new cluster
> 
>     2.  shut down the old cluster and copy/link the data files
> 
> 
> When we were discussing this, I was thinking that the linking could be done in
> phase 1 too, as that's potentially slow on a very large schema.

Uh, good point!  You can create the hard links while system system is
running, no problem!  It would only be copy that can't be done while the
system is running.  Of course a big question is whether hard linking
takes any measurable time.

-- 
  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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Speeding up pg_upgrade
Next
From: Stephen Frost
Date:
Subject: Re: Speeding up pg_upgrade