>You're right; the capability is not there now.

Whew! 

>The only "automated" tool that generates "listener paths" (I 
>don't know what better to call them) is the "init_cluster.pl" 
>tool in the altperl directory.
>
>If you run that, with the new configuration, it'll generate 
>suitable SET LISTEN statements for all the necessary paths.

Do you mean "STORE LISTEN"?

>What I'd like to do for 1.1 is for these "listen paths" to be 
>generated automatically and revised after one runs SUBSCRIBE 
>SET.  The heuristic would be:
>
> - Any time a node is added, "listen paths" can be added that 
>point to the origin for one of the sets.  That's good enough 
>to get communications going.

Oh, right, for a big cluster with multiple sets this makes more sense
than what I was thinking:
full cross-product for the existing network and the new node - in our
case we really only have one set for each cluster (famous last
words...). 

So maybe STORE NODE would take and additional option like "DEFAULT SET"?

> - Any time SUBSCRIBE SET completes, for a node, drop all 
>paths that attach to it, and revise them to go through 
>whereever that subscription "comes from."

Though if a given node can be subscribed to multiple sets, you wouldn't
just want to delete all
existing paths for that node, would you, assuming that it might already
be subscribed to one
or more sets?

And I guess you'd want to do the inverse for an "UNSUBSCRIBE SET".

In this model it seems like there would need to be a closer relationship
in the schema between set and path/listen than there is currently. For
instance, if a node subscribes to two sets from an origin, it's possible
that it would want to do this over different interfaces. We will have
this situation in our app in the future: our current replication cluster
communicates over an interface associated with a cross-over cable
between two machines, but we will be adding a third node in the future,
which will be geographically remote, and so will need a separate
interface. Maybe something like this is already being contemplated?

I'm in danger of digressing, but related to this topic, it might be
helpful to have a "default" conninfo associated with the node. In the
logic I am implementing to generate the path/listens for a new node, I
am just getting the unique set of paths by pa_server, which is not
really all that safe (eg, when we add or third geographically
distributed node). Maybe differentiating paths based on set subscription
would remove the need for this, though.....

Thanks.

- DAP