Andrew Sullivan <ajs at crankycanuck.ca> writes:
> On Tue, Jul 27, 2004 at 10:55:00AM -0400, David Parker wrote:
>> I would like to start building a small set of perl tools for my slony
>> system (add/remove a host to a cluster, add a new table to a set,
>> reporting, etc). 
>
> Chris Browne told me before I left Toronto last week that he'd be
> checking in some scripts that would do several of these things (as a
> "stock" part of Slony) Real Soon Now.  So, rather than having to
> reinvent the wheel, maybe you want to have a look at that stuff
> first.  Chris?

They're checked in now; look for the directory "altperl."

After having fought pretty furiously with the code that generates the
STORE LISTEN requests, I'm coming to the thought that this perhaps
ought to be managed on the plpgsql side, generated "automatically" by
virtue of having, in the Slony schema, an indication of the shape of
the tree that is supposed to connect the nodes.

In effect, each node, aside from the origin, would have to have a
desired "parent."

Based on having "parentage" data, several things can be done:

 - A node can rummage through the "parentage" information and use it
   to drop and recreate all of the sl_listen entries.

   (I have a dynamic programming formulation that'll do it that I'd
   like to translate to plpgsql; it's probably not provably the
   optimal way to build this, but I'm confident it's more than fast
   enough for any node set of reasonable size ;-).)

 - You can verify whether a node is a legitimate parent or not based
   on whether it was configured to forward requests.  (There was a
   recent complaint about this...)  In effect, you can't set up a node
   as a child of a particular parent if the parent isn't a forwarder.

   There may be other appropriate foreign key constraints relevant to
   this; not sure offhand...
-- 
(reverse (concatenate 'string "ofni.sailifa.ac" "@" "enworbbc"))
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)