> On 06 Feb 2018, at 01:09, David Fetter <da...@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
