Re: [HACKERS] WIP: Failover Slots

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] WIP: Failover Slots
Дата
Msg-id CA+TgmoZsrQm+ALJDjMhfsvPJ3pHAAdSV363oiV6oOkBFc=ihEg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] WIP: Failover Slots  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: [HACKERS] WIP: Failover Slots  (Craig Ringer <craig@2ndquadrant.com>)
Re: [HACKERS] WIP: Failover Slots  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Tue, Jul 25, 2017 at 8:44 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> No. The whole approach seems to have been bounced from core. I don't agree
> and continue to think this functionality is desirable but I don't get to
> make that call.

I actually think failover slots are quite desirable, especially now
that we've got logical replication in core.  In a review of this
thread I don't see anyone saying otherwise.  The debate has really
been about the right way of implementing that.  Suppose we did
something like this:

- When a standby connects to a master, it can optionally supply a list
of slot names that it cares about.
- The master responds by periodically notifying the standby of changes
to the slot contents using some new replication sub-protocol message.
- The standby applies those updates to its local copies of the slots.

So, you could create a slot on a standby with an "uplink this" flag of
some kind, and it would then try to keep it up to date using the
method described above.  It's not quite clear to me how to handle the
case where the corresponding slot doesn't exist on the master, or
initially does but then it's later dropped, or it initially doesn't
but it's later created.

Thoughts?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] Subscription code improvements
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] [PATCH] Make ExplainBeginGroup()/ExplainEndGroup() public.