Re: status/timeline of pglogical? - Mailing list pgsql-advocacy

On Wed, May 11, 2016 at 7:10 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> The only reason this has been brought up is that pglogical is a tool
> designed to reduce the impact of upgrades. No other tool has ever been
> available externally to do that, apart from pg_upgrade which was accepted
> into core in quite a poor state. So this discussion has not been about
> "external tools" it has been about the one and only external tool that
> provides an improved upgrade route.

I want to be clear that I'm not disputing this contention (well, open
source tool, maybe).  I also want to be clear that I agree with your
assessment of pg_upgrade.  Where we may disagree is on what that
implies:

1. I think pglogical needs some additional work so that we don't again
end up with a tool that should help with upgrades but actually isn't
quite fully baked.

2. I also think pglogical should be integrated into the core
distribution, because it makes little sense to me to have logical
decoding in core but nothing that can take advantage of that
capability in core.  External tools can continue to exist to provide
extra capabilities that aren't in core yet based on the same
infrastructure, but the core capabilities should be in the core
distribution.

3. I think we need to replace pg_upgrade with a real in-place upgrade
scheme so that you just fire up the new version of the server on your
old data directory, and it rejiggers things in place without needing
to create a new cluster and migrate stuff over to it.  I think that
actually making this work is a huge engineering effort, and I have no
plans to undertake it in the near term, but I think it has to be done.
pg_upgrade isn't reliable enough, and using pglogical means you need a
second machine.  Maybe everybody should run with a standby, but not
everyone does.

4. In the absence of a pg_upgrade replacement, more work out to be
done to file down the rough edges of pg_upgrade.  For example, Tom's
work to make the server run in single-user mode via a pipe would have
made pg_upgrade safer, but it got shouted down because it wasn't free
ice cream and a pony.  That is a shame.

Of course, your conclusions may be different, and that's fine.  This
is just what I think.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company