Re: Design for In-Core Logical Replication

On 20 July 2016 at 17:52, Rod Taylor <rod(dot)taylor(at)gmail(dot)com> wrote:

> I think it's important for communication channels to be defined separately
> from the subscriptions.
>

I agree and believe it will be that way.

Craig is working on allowing Replication Slots to failover between nodes,
to provide exactly that requested behaviour.

> So, I'd rather have:
>
> CREATE CONNECTION machine1;
> CREATE CONNECTION machine2;
>

I think those map to replication slots. (This discussion might get a bit
confusing if we try to guess exactly what each others terms mean, so I'll
go no further than "I think").

> CREATE SUBSCRIPTION TO PUBLICATION mypub;
>

Yep

> I'm not certain the subscription needs to be named. IMO, a publication
> should have the same properties on all nodes (so any node may become the
> primary source). If a subscriber needs different behaviour for a
> publication, it should be created as a different publication.
>

Understood, its mostly to allow it to be dropped or altered and monitored.
It's kindof like an index, it needs a name, we just don't much care what it
is.

> Documenting that ThisPub is different from ThatPub is easier than
> documenting that ThisPub on node 1/2/4 is different from ThisPub on node
> 7/8, except Node 7 is temporarily on Node 4 too (database X instead of
> database Y) due to that power problem.
>

Which is why pg_dump support is important to allow us to sync up the
definitions.

> Clearly this is advanced. An initial implementation may only allow mypub
> from a single connection.
>

Good input and clearly explained, thanks. If any of the above changes,
these requirements will remain noted.

> I also suspect multiple publications will be normal even if only 2 nodes.
> Old slow moving data almost always got different treatment than fast-moving
> data; even if only defining which set needs to hit the other node first and
> which set can trickle through later.
>

Agreed

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services