Sv: Better Upgrades - Mailing list pgsql-hackers

From Andreas Joseph Krogh
Subject Sv: Better Upgrades
Date
Msg-id VisenaEmail.0.3adac2985cfafbf2.1616a845dca@tc7-visena
Whole thread Raw
In response to Better Upgrades  (David Fetter <david@fetter.org>)
List pgsql-hackers
På tirsdag 06. februar 2018 kl. 01:09:18, skrev David Fetter <david@fetter.org>:
Folks,

While chatting with Bruce about how to make something better than
pg_upgrade, we (and by "we," I mean mostly Bruce) came up with the
following.

What needs improvement:

- pg_upgrade forces a down time event, no matter how cleverly it's done.
- pg_upgrade is very much a blocker for on-disk format changes.

The proposal:

- Add a new script--possibly Perl or Bash, which would:
    - Initdb a new cluster with the new version of PostgreSQL and a
      different port.
    - Start logical replication from the old version to the new
      version.
    - Poll until a pre-determined default amount of replication lag was observed, then:
      * Issue an ALTER SYSTEM on the new server to change its port to the old server's
      * Issue a pg_ctl stop -w to the old server
      * Issue a pg_ctl restart on the new server
      * Happiness!

Assumptions underlying it:

- Disk and similar resources are cheap enough for most users that
  doubling up during the upgrade is feasible.
- The default upgrade path should require exactly one step.
- Errors do not, by and large, have the capacity to violate an SLA.

The proposal has blockers:

- We don't actually have logical decoding for DDL, although I'm given
  to understand that Álvaro Herrera has done some yeoman follow-up
  work on Dimitri Fontaine's PoC patches.
- We don't have logical decoding for DCL (GRANT/REVOKE)
 
- Need to add support for decoding LargeObjects.
 
--
Andreas Joseph Krogh

pgsql-hackers by date:

Previous
From: Arthur Zakirov
Date:
Subject: Re: [HACKERS] Bug in to_timestamp().
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] path toward faster partition pruning