Speeding up pg_upgrade

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Speeding up pg_upgrade
Date: 2017-12-05 14:01:35
Message-ID: 20171205140135.GA25023@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

My question is whether the schema dump/restore is time-consuming enough
to warrant this optional more complex API, and whether people would
support adding a server setting that prevented all system table changes?

Bruce Momjian <bruce(at)momjian(dot)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 +


Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2017-12-05 14:16:02 Re: Speeding up pg_upgrade
Previous Message Rafia Sabih 2017-12-05 13:02:52 Re: [HACKERS] [POC] Faster processing at Gather node