Re: [HACKERS] WIP: Failover Slots - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] WIP: Failover Slots
Date
Msg-id CA+TgmoZsrQm+ALJDjMhfsvPJ3pHAAdSV363oiV6oOkBFc=ihEg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] WIP: Failover Slots  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [HACKERS] WIP: Failover Slots  (Craig Ringer <craig@2ndquadrant.com>)
Re: [HACKERS] WIP: Failover Slots  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Subscription code improvements
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] [PATCH] Make ExplainBeginGroup()/ExplainEndGroup() public.