"Henry - Zen Search SA" <henry at zen.co.za> writes:
> Just to wrap up this thread:
>
> Doing:
>
> select  _db_cluster.setdroptable_int(121);
>
> Produces the error:
>
> ERROR:  Slony-I: alterTableRestore(): Table with id 121 not found
>
> ---
>
> I think I've screwed things somewhere along the line with my tinkering and
> will rather acknowledge the lesson well learned -- and as David suggested
> from the start, drop replication from the nodes, and restart from scratch.
>  Things will only get worse from here on out, wasting everyone's time.
>
> Thank you to everyone who assisted.

Actually, no, I don't think you have "mucked things up further" at
this point...

That error message doesn't surprise me too much, based on the scenario
you described.

What I *think* would probably work to clean things up would be
outlined thus:

- On each node, clean out the configuration for table #121

  - On the "master" node, where you had actually dropped the table,
    this solely involves deleting the entry in sl_table.

    e.g. - "delete from _db_cluster.sl_table where id = 121;"

  - On other nodes, where the table hasn't been mucked with, you can
    pretty cleanly drop the table from replication via:

    select  _db_cluster.setdroptable_int(121);

  Once one of those two actions has been taken everywhere, you can add
  the table back to replication...

- Make sure the table is present on all nodes

- Submit slonik script consisting of:

  CREATE SET for a new set
  SET ADD TABLE to add your errant table to the new set
  SUBSCRIBE SET as many times as needed to get the table replicating

- Once replication is back working on that table...
  Slonik MERGE SET will merge the new set into the old one so that
  you don't have the complexity of extra replication sets in your
  configuration

-- 
output = ("cbbrowne" "@" "linuxdatabases.info")
http://www3.sympatico.ca/cbbrowne/nonrdbms.html
A Linux  machine!  because  a 486  is a terrible  thing to  waste!  
-- <jjs at wintermute.ucr.edu> Joe Sloan