On Thu, Oct 18, 2007 at 10:15:17AM +0200, Henry - Zen Search SA wrote:
> 
> An automated script which was missed dropped one of the tables which is
> part of the replication set.

I think we need more information to help you.  Do you mean a script
performed 

	DROP TABLE tablename

on the origin, and not on the replica?

If so, then yes, you have some problems.

What you need to do is use the internal functions of slony on the
replicas to remove that table from the replication set.  This is the
man page you want to read:

http://slony.info/documentation/function.setdroptable-int-integer.html

Then, you drop the table on the replica.  If you want to have it back
again, don't drop it, but you can TRUNCATE it if you want.  Rebuild
the table on the origin, add it to a _new_ set and subscribe the
replica to it.  Then, optionally, MERGE SET to put it back into the
single set you have.  And _make sure_ you don't have any other
"automated scripts" helpfully cleaning out tables for you ;-)

I strongly suggest you try this out several times on a test system,
make a script that performs all the commands for you, and then use
that script to do the work.  This is not the sort of operation you
want to fat finger.

A

-- 
Andrew Sullivan  | ajs at crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism. 
                --Brad Holland