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/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services