Re: [HACKERS] Replication origins and timelines

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: [HACKERS] Replication origins and timelines
Дата
Msg-id CAMsr+YFt+Ao4faYYe-9JhYNkJcrfaYPWMZ258LTD2W4Dxz4VyQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Replication origins and timelines  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: [HACKERS] Replication origins and timelines  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] Replication origins and timelines
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] pg_class.relpartbound definition overly brittle