Re: [HACKERS] Replication origins and timelines - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [HACKERS] Replication origins and timelines
Date
Msg-id CAMsr+YFt+Ao4faYYe-9JhYNkJcrfaYPWMZ258LTD2W4Dxz4VyQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Replication origins and timelines  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] Replication origins and timelines  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On 1 June 2017 at 09:27, Stephen Frost <sfrost@snowman.net> wrote:
> Craig,
>
> * Craig Ringer (craig@2ndquadrant.com) 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.
>
> Uh, TL;DR, wow?  Why isn't this something which needs to be addressed
> before PG10 can be released?  I hope I'm missing something that makes
> the current approach work in PG10, or that there's some reason that this
> isn't a big deal for PG10, but I'd like a bit of info as to why that's
> the case, if it is.

In Pg 10, if you promote a physical replica then logical replication
falls apart entirely and stops working. So there's no corruption
hazard because it just ... stops.

This only starts becoming an issue once logical replication slots can
exist on replicas and be maintained to follow the master's slot state.
Which is incomplete in Pg10 (not exposed to users) but I plan to
finish getting in for pg11, making this a possible issue to be
addressed.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Replication origins and timelines
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] pg_class.relpartbound definition overly brittle