On 20 July 2016 at 17:52, Rod Taylor <rod.tay...@gmail.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:

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").



> 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

> 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

> 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.


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

Reply via email to