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/