Andrew Sullivan wrote:
> On Wed, Jan 28, 2009 at 07:08:05PM -0500, Geoffrey wrote:
>> We have determined that we will have to shutdown slony in order to add  
>> tables to our databases.  This is because we have code that stops all  
>> triggers from firing, thus we've had to set our Slony triggers to  
>> 'enable always'.
> 
> Sounds like you ought to fix your code ;-)

I'm working on that, but there's a difference in philosophy here.  I've 
just got to convince them I'm right and their wrong. ;(

>> That being said, would it be possible to add a table to our master  
>> database while slony is active without causing problems to our 
>> replication?
> 
> Yes.  Slony cares about what's in its sets, not about tables it knows
> nothing about.  Add the table and start using it; just remember that
> it won't be copied.

Awesome, as I thought.

>> Further, would it then be possible to add the changes to our slave at a  
>> later time and permit slony to properly 'catch up' on that table, while  
>> simply picking up where it left off on the others?
> 
> Maybe.  I'm not sure I understand what you mean.  But what you do,
> when you're ready to make the change, is create a new set, add the
> table to it, and let it sync up with the replica.  When it's caught up
> more or less, then you can merge set if you want.

Actually, I think you do. ;)

So I would not add it to an existing set, I would simply create a new 
set, with that table in it?  That really is a better approach then I was 
considering.

So, the fact that I use the altperl scripts and the slon_tools.conf 
configuration file approach to my databases, I can simply add a new set 
to my existing configuration and then run the appropriate commands to 
get that table to sync?

-- 
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin