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
Re: [HACKERS] WIP: Failover Slots |
Список | 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 по дате отправления: