I did a little mistake

pg_dump -N _the_name_of_clustername -Fc -f yourdump.dmp -h... -p... -U.... ....


First generate the TOC using -l


pg_restore -lyourdump.dmp | grep -v the_name_of_clustername > toc.safe

Then restore using the new toc and -L


pg_restore -L toc.safe yourdump.dmp




________________________________
 De : David TECHER <davidtecher at yahoo.fr>
À : Stuart Bishop <stuart at stuartbishop.net>; slony <slony1-general at lists.slony.info> 
Envoyé le : Mardi 29 Novembre 2011 14h13
Objet : [Slony1-general] Re :  dump, restore & --exclude-schema
 

You need to exclude the triggers

Make the dump using -Fc and not -Fp

pg_dump -N _the_name_of_clustername .... yourdump.dmp

First generate the TOC using -l


pg_dump -l yourdump.dmp | grep -v the_name_of_clustername > toc.safe

Then restore using the new the new toc

pg_restore -L toc.safe yourdump.dmp


________________________________
 De : Stuart Bishop <stuart at stuartbishop.net>
À : slony <slony1-general at lists.slony.info> 
Envoyé le : Mardi 29 Novembre 2011 13h33
Objet : [Slony1-general] dump, restore & --exclude-schema
 
Hi.

I was hoping to get 'clean' dumps from a slave now that I have
upgraded from the Slony-I 1.2 series using --exclude-schema. However,
the --exclude-schema option to pg_dump is still dumping all the slony
triggers attached to the tables:

CREATE TRIGGER _sl_denyaccess
    BEFORE INSERT OR DELETE OR UPDATE ON accesspolicy
    FOR EACH ROW
    EXECUTE PROCEDURE
 _sl.denyaccess('_sl');

This creates a dump that I cannot seem to restore error free -
pg_restore tries to create the triggers and fails, causing hundreds of
errors to be reported and, more importantly to my automation scripts,
return an error code.

Should I be doing something differently, or do I need to continue to
dump my database with the Slony-I schema and then 'repair' it using
"DROP SCHEMA _sl CASCADE;" as I have been in the past? I need
something that can be automated, as our production dumps are regularly
used to rebuild some staging servers (with the nice side effect of
testing our dumps and disaster recovery processes).

I'm considering creating a stub slony schema and denyaccess stored
procedure, but I'm not sure if that solution is better than the
mechanism I used with slony 1.2 (dump the whole database, including
the seemingly useless Slony schema, and repair it after
 restoration).

-- 
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/
_______________________________________________
Slony1-general mailing list
Slony1-general at lists.slony.info
http://lists.slony.info/mailman/listinfo/slony1-general



_______________________________________________
Slony1-general mailing list
Slony1-general at lists.slony.info
http://lists.slony.info/mailman/listinfo/slony1-general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20111129/5b1d5e6c/attachment.htm