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@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 +
