On 04/04/16 17:15, Andres Freund wrote:

* Robust sequence decoding and replication. If you were following the later
parts of that discussion you will've seen how fun that's going to be, but
it's the simplest of all of the problems.

Unconvinced. People used londiste and slony for years without that, and
it's not even remotely at the top of the list of problems with either.

Londiste and Slony also support physical failover unlike logical decoding which is the main point of this discussion, lets not forget that.

* Robust, seamless DDL replication, so things don't just break randomly.
This makes the other points above look nice and simple by comparison.

We're talking about a system which involves logical decoding. Whether
you have failover via physical rep or not, doesn't have anything to do
with this point.

It is if you are insisting on using logical rep as solution for failover.

I don't think there's any realistic way we're going to get there for
logical rep in 9.6+n for n<2 unless a whole lot more people get on board
and work on it. Even then.

I think the primary problem here is that you're focusing on things that
just are not very interesting for the majority of users, and which thus
won't get very enthusastic help.  The way to make progress is to get
something basic in, and then iterate from there.  Instead you're
focussing on the fringes; which nobody cares about, because the basics
aren't there.

Craig is focusing on solving failover for logical slots which is very damn basic issue with logical decoding right now no matter if we have logical replication in core or not. I personally don't think it's ok by any means to not be able to continue logical decoding on failover event 2 versions after logical decoding was introduced.

I also don't buy your argument that it's unsafe to use timeline following on logical decoding on replica. You can always keep master from moving too far ahead by other means (even if you just use dummy slot which is only used for this purpose, yes ugly I know). If we got failover slots into 9.6 it would be better but that does not look realistic at this point. I don't think that current design for failover slots is best possible - I think failover slots should be created on replica and send their status up to the master which would then take them into account when calculating oldest needed catalog xmin and lsn (simple way of doing that would be to add this to feedback protocol and let physical slot to keep the xmin/lsn as well), but that does not mean timeline following isn't good thing on it's own (not to mention that iterative development is a thing).

  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:

Reply via email to