Re: A Modest Upgrade Proposal

On 13/07/16 21:06, Robert Haas wrote:
>
>> We have much to discuss in terms of security, the way it should work and
>> what options to support and a sidetrack into syntax isn't warranted at this
>> early stage. Please lets discuss those important things first, then return
>> to whether DDL makes sense or not; it may do, or may not, or more likely
>> which parts of it need DDL and which do not.
>
> We've sort of hijacked this whole thread which was originally about
> something different, so maybe it would be better to start a new thread
> specifically to talk about the design of logical replication.  For my
> money, though, I don't find the designs I've seen so far to be
> particularly compelling - and I think that the problem is that we tend
> to think about this from the point of view of the capabilities that
> must be available within a single instance.
> ...>
> Similarly, for logical replication, users will want to do things like
> (1) spin up a new logical replication slave out of thin air,
> replicating an entire database or several databases or selected
> replication sets within selected databases; or (2) subscribe an
> existing database to another server, replicating an entire database or
> several databases; or (3) repoint an existing subscription at a new
> server after a master change or dump/reload, resynchronizing table
> contents if necessary; or (4) stop replication, either with or without
> dropping the local copies of the replicated tables.  (This is not an
> exhaustive list, I'm sure.)
>

Well this all can be done using pglogical so I don't really understand 
what you mean when you say that you don't like the design or what's the 
actual problem here (although I don't plan to implement everything in 
the first patch submission).

> I don't mean to imply that the existing designs are bad as far as they
> go.  In each case, the functionality that has been built is good.  But
> it's all focused, as it seems to me, on providing capabilities rather
> than on providing a way for users to manage a group of database
> servers using high-level primitives.  That higher-level stuff largely
> gets left to add-on tools, which I don't think is serving us
> particularly well.  Those add-on tools often find that the core
> support doesn't quite do everything they'd like it to do: that's why
> WAL-E and repmgr, for example, end up having to do some creative
> things to deliver certain features.  We need to start thinking of
> groups of servers rather than individual servers as the unit of
> deployment.
>

You can't build the highlevel management parts without first having the 
per node lower level parts done. It would be nice to have highlevel 
parts as well but nobody wrote that so far. I hope you don't expect 
logical replication patch to do all that, because if you do, you'll be 
disappointed.

--   Petr Jelinek                  http://www.2ndQuadrant.com/  PostgreSQL Development, 24x7 Support, Training &
Services