On 12/1/2010 11:03 AM, Paweł Tęcza wrote:
> Dnia 2010-12-01, śro o godzinie 17:30 +0200, Devrim GÜNDÜZ pisze:
>>  On Wed, 2010-12-01 at 16:27 +0100, Paweł Tęcza wrote:
>>  >
>>  >  What is an official way for purging Slony
>>  >  schema/columns/functions/whatever from a database?
>>  >
>>  >  Can I use slonik_* scripts for that task? What script order should be?
>>  >  slonik_unsubscribe_set, slonik_drop_set, slonik_uninstall_nodes, drop
>>  >  schema _replication?
>>
>>  After killing slons, slonik_uninstall_nodes should be sufficient.
>
> Vick and Devrim,
>
> Thanks a lot for your rapid reply! :D
>
> Before sending my post here I was trying to purge Slony in a following
> way:
>
> myDB=# drop schema _replication cascade;
> NOTICE:  drop cascades to 274 other objects
> DETAIL:  drop cascades to type _replication.xxid
> [...]
> drop cascades to function _replication.denyaccess()
> drop cascades to function _replication.lockedset()
> and 174 other objects (see server log for list)
> DROP SCHEMA
>
> # slonik_unsubscribe_set 1 10 |slonik
> <stdin>:13: unsubscribed node 10 from set 1
>
> # slonik_drop_set set1 |slonik
> <stdin>:6: PGRES_FATAL_ERROR select "_replication".dropSet(1);  - ERROR:
> schema "_replication" does not exist
>
> # slonik_uninstall_nodes
> cluster name = replication;
> node 1 admin conninfo='host=hostM dbname=myDB user=slony port=5432
> password=secret';
> node 10 admin conninfo='host=hostS dbname=myDB user=slony port=5432
> password=secret;
>    uninstall node (id=10);
>    uninstall node (id=2);
>
> slonik_* scripts removed a lot of Slony stuff, but they didn't drop only
> one column called "_Slony-I_replication_rowID" from tables of my
> database. Finally I dropped them by hand (alter table ... drop
> column ...).
>
> Probably it was my fault that I dropped the schema before dropping set
> "set1".

That was definitely a mistake. Never do that unless you are on Slony 2.0.x.

For subscribers under version < 2.0 there is the possibility to be left 
with a corrupted system catalog that is rather tricky (and risky) to 
recover from. This will be the case if your schema has any user defined 
triggers or foreign keys.

The master database should be fine regardless.




-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin