The documentation tree includes docs about the stored functions, which
are probably the way to do this.
The problem of course is that everyone's pretty busy. Jan is
evidently pretty much hiding after he got back from France, and I have
had no lack of things to do.
There's some useful "protocol" to consider when looking at those
stored functions, as there are generally two for each action:
1. A "main" one, which gets invoked on one node
e.g. - to add a path between nodes, you call
storepath( integer, integer, text, integer )
These sometimes can be called "anywhere," but often need to be
called on the node where some interesting action is supposed to
take place. That way, the procedure can successfully check the
state of that node and give a decent error message if it fails.
If the action looks like it'll succeed, Slony-I "raises an event"
to broadcast the activity to everywhere else.
2. Then, there's an "internal" one that does internal work that
should be done on each node.
storepath_int ( integer, integer, text, integer )
When the 'STORE_PATH' event gets broadcasted everywhere, this
"internal" function is used to make the event take effect
"everywhere."
Thus, it's important to run the right functions, and sometimes to run
them on the right node. With storepath(), where to run it isn't
important, as it'll broadcast paths onwards as it propagates. But
with subscribeset(), it had better initially run on the node that's
supposed to be doing the subscribing.
That's reasonably well documented in the functions themselves, so that
trial and error will get you somewhere...
--
(format nil "~S@~S" "cbbrowne" "gmail.com")
http://linuxdatabases.info/~cbbrowne/slony.html
Blood is thicker than water, and much tastier.