Re: Timeline following for logical slots - Mailing list pgsql-hackers

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