Hi, On 2017-06-01 09:12:04 +0800, Craig Ringer wrote: > TL;DR: replication origins track LSN without timeline. This is > ambiguous when physical failover is present since XXXXXXXX/XXXXXXXX > can now represent more than one state due to timeline forks with > promotions. Replication origins should track timelines so we can tell > the difference, I propose to patch them accordingly for pg11.
I'm not quite convinced that this should be tracked at the origin level. If you fail over physically, shouldn't we also reconfigure logical replication? Even if we decide this is necessary, I *strongly* suggest trying to get the existing standby decoding etc wrapped up before starting something nontrival afresh. > Why? > > Take master A, its physical replica B, and logical decoding client X > streaming changes from A. B is lagging. A is at lsn 1/1000, B is only > at 1/500. C has replicated from A up to 1/1000, when A fails. We > promote B to replace A. Now C connects to B, and requests to resume at > LSN 1/1000. Wouldn't it be better to solve this by querying the new master's timeline history, and checking whether the current replay point is pre/post fork? I'm more than bit doubtful that adding more overhead to every relevant record is worth it here. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
