On 28 April 2015 at 05:38, Jim Nasby <Jim.Nasby@xxxxxxxxxxxxxx> wrote:
On 4/26/15 7:49 AM, Craig Ringer wrote:
There are also some improvements needed to the user interface - in
particular, providing a function interface for changing replication set
memberships for connections so there's no need to manually restart the
apply backends after a change, and providing default replication sets
for a node.
If 'default replication set' is the idea of "here's what tables *should* be getting replicated regardless of whether that's happening or not", it'd be great if that was done so it could be split out on it's own at some point. It's a problem that affects all replication systems.
It wasn't, but that's an interesting idea.
You need away to identify peer nodes in an abstract way before you can really define sets of which nodes should get which tables. So I think replication identifiers ( https://commitfest.postgresql.org/4/161/ ) are a pre-requisite for that though, and one that's proving difficult to get in.
I think any sort of replication sets is likely to have similar problems, especially the "no in-core user" problem. There's nothing fundamentally impossible about filtering WAL sent to physical downstreams over streaming replication to include only replicated tables and the catalogs, though, so perhaps there could be an in-core user for it.
In BDR we're currently (ab)using security labels to tag tables with their replication sets, but I'd love to have a proper way to do that. As I recall the prior approach, of allowing custom relation options, was rejected on -hackers.
How would you want to go about storing and tracking the information? A new catalog? The other issue for in-core replication sets would probably be making it foreign-key aware, so replication of a table transitively requires replication of its references.
