On Thu, October 18, 2007 1:46 pm, Andrew Sullivan wrote:
> 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.

Yes, this is what happened.  A miserable little legacy script floating
around (instead of DELETEing, it DROPped and repopulated - don't ask).

> 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 ;-)

Thanks, will give this a try.

> 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.

Yup, very true.

Thank you very much for the pointers.

Regards
Henry