Thanks, Jennifer - I finally got this to work
Not sure exactly why - I'll describe the scenario and welcome comments:
   1. UNSUSCRIBE SET
   2. Drop SET 1 on master (containing the original 7 tables)
      a. Drop associated paths
      b. Drop associated listens
   3. Drop SET 99 on master (containing the 8th table)
   4. Drop slave node (node 2 - running from master)
   5. Login to slave and sql delete node 99
       (delete from sl_set where id = 99)
   

Did this all yesterday. The slony log was still producing the error
  (node -1 not found in runtime configuration)
The missing piece I believe was that the Postgres server got restarted
Last night WITH THE SLONS STILL RUNNING:
   This morning I looked at the slony logs running and didn't
   See the error after the restart.  Slony restarted, removed a stale   
    Nodelock and essentially cleaned itself up.

  6. Did another CREATE SET, including all 8 tables in the replication
     a. STORE PATH(s)
     b. STORE LISTEN(s)

  7. SUBSCRIBE SET 1

The slon took about 10 minutes to catch up replicating then we were good to
go. 
One thing I think I was doing wrong (again I welcome comments) was that
I manually killed the slons every time I received the node -1 error
I would restart them when I attempted another solution.  I guess Slony
Needs to be allowed to clean itself up.

Hopefully this will help someone avoid this pain in the future.
      (Add to Doc?)  I'll help any way I can.

________________________________

Mark Steben│Database Administrator│ @utoRevenueT
480 Pleasant Street, Suite B200, Lee, MA 01238 
413-243-4800 x1512 (Phone) │ 413-243-4809 (Fax)
A Division of Dominion Enterprises

 
 
 
 
 
-----Original Message-----
From: Jennifer Spencer [mailto:jennifer.spencer at stanford.edu] 
Sent: Monday, August 11, 2008 4:52 PM
To: Mark Steben
Cc: 'chris'; slony1-general at lists.slony.info
Subject: Re: [Slony1-general] RE: node -1 error after restarting servers

Hi Mark - I have had this problem myself.  The only way I solved it was to
remove all reference to the 
set merge/creation (set 99 in your case) from my sl_events table.  It's not
enough to remove 
references to the set from your sl_set and sl_table tables, unfortunately.

It's a little tricky to find the event number you need to remove once you've
gotten rid of the set 
from sl_set, sl_table, etc.  Maybe someone else here will chime in on that?

-Jennifer

Mark Steben wrote:
> 
> Thanks Chris for the response,
> 
> I have tried to restart the slons several times with no success.
> 
> I should have added that, prior to this problem, I was succesfully
> Replicating 7 tables.
> Then I added an 8th table to the replication through the recommended
> scenario of
>  CREATE SET (Set add table)
>  SUBSCRIBE SET
>  MERGE SET
> 
> This worked.  Now, upon further investigation, I do a query
>  On the slave:
> 
> select * from sl_set   
> slony_practice-# ;
>  set_id | set_origin | set_locked |          set_comment           
> --------+------------+------------+--------------------------------
>       1 |          1 |            | 7 mavmail tables
>      99 |          1 |            | merged feedback response table
> 
>  
> But On the master: 
>  
>  slony_practice=# select * from sl_set;
>  set_id | set_origin | set_locked |     set_comment      
> --------+------------+------------+----------------------
>       1 |          1 |            | 7 + 1 mavmail tables
> 
> 
> This condition occurs because, when I restarted the servers I did a
> DROP SET / CREATE SET set of sloniks on the master where I recreated the
> Set 1 with all 8 tables and dropped set 99. So now obviously I need to
> Get them back in sync.  I tried a DROP SET on the slave to attempt to
> Drop set 99 but it errors out saying that:
>   
> "set 99 does not originate on local node:
> 
> And I tried the same thing on the master node and got the same message.
> 
> Do I need to rerun the entire MERGE SET scenario where I create set 99 on
> the master again?
> 
> Thanks for your time.
> 
> Mark
> 
> From: chris [mailto:chris at dba2.int.libertyrms.com] 
> Sent: Monday, August 11, 2008 10:56 AM
> To: Mark Steben
> Cc: slony1-general at lists.slony.info
> Subject: Re: [Slony1-general] RE: node -1 error after restarting servers
> 
> "Mark Steben" <msteben at autorevenue.com> writes:
>> I messed up and sent this originally as HTML.  Resending as plain text.
> 
> Thanks, that's helpful!
> 
>> Hi - hoping for some help.
>> I'm running Slony 1.2.14 on a simple 1 master 1 slave configuration.
Each
>> server is running Postgres 8.2.5.
>> I had to restart both master and slave servers.  When I tried to restart
> the
>> slons I got errors in the slave log that
>> Table ids were already assigned within the set.  So I dropped the set,
>> dropped the path and the listens,
>> And recreated all with CREATE SET,  STORE PATH, and STORE LISTENS on the
>> provider
>>
>> Now when I restart the slons and subscribe the newly defined set I get
the
>> following error in the logs
>> On the slave:
>>     node -1 not found in runtime configuration
>>
>> and the copy fails.
>>
>> When I query SL_NODE on the master I get:
>>
>>    no_id | no_active |   no_comment    | no_spool 
>> -------+-----------+-----------------+----------
>>      1 | t         | Master Node     | f
>>      2 | f         | <event pending> | f
>>
>> And the same query on the slave gives:
>>
>> no_id | no_active |        no_comment        | no_spool 
>> -------+-----------+--------------------------+----------
>>      1 | t         | Master Node                    | f
>>      2 | t         | subscriber node                | f
>> (2 rows)
>>
>> Do I have to recreate the node(s) as well?   
>>
>> Any help would be appreciated.  thanks
> 
> That error message takes place at the beginning of the function
> "copy_set", and indicates that the slon couldn't find the node in the
> in-memory configuration.
> 
> That can commonly be rectified by restarting the slon, which will
> cause the slon to reread its configuration.
> 
> Except, we should take a step back.  The trouble is that copy_set()
> was trying to access a node that it wasn't properly aware of.
> 
> The data that you have provided about sl_node on both nodes looks
> useful, actually.  It indicates that the "master" node hasn't yet
> figured out its configuration, which seems quite plausible to cause
> further troubles.
> 
> If I had to guess, I'd imagine that perhaps you hadn't run a slon
> against the "master" node and that it isn't properly aware, yet, that
> node #2 has been set up.
> 
> Before you start trying to set up subscriptions, make sure you can run
> things like "STORE PATH" and see, in the logs, that this has been
> processed by both nodes.