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:
http://www.postgresql.org/mailpref/pgsql-hackers
