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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
