> On 06 Feb 2018, at 01:09, David Fetter <david@fetter.org> wrote:
> - pg_upgrade is very much a blocker for on-disk format changes.
I wouldn’t call it a blocker, but pg_upgrade across an on-disk format change
would be a very different experience from what we have today since it would
need to read and rewrite data rather than hardlink/copy. Definitely not a
trivial change though, that I completely agree with.
> 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!
Considering how many that will want to build frontends for upgrade tools, or
include them in automation frameworks, I think it would be wise to make any new
upgrade tool capable of emitting machine parseable status information (or any
equivalent means of “what is it doing right now” interrogation). Thats not
specific for this tool of course, more a general observation regarding upgrade
tools and their usage.
cheers ./daniel
