We ran into some weirdness applying a schema change to the slave
databases.  The change was to DROP a table which was not replicated
but had a foreign key referenceto a table which is replicated.  It
worked fine on the master database but broke on the slave databases.

vodlive_slave1=# drop table mc_today_xtns
ERROR:  "pk_mc_subscribers" is an index

My suspicion was that it was related to the foreign key from
mc_today_xtns to mc_subscribers.

    "fk_mc_today_xtns_mc_subscriber" FOREIGN KEY (mc_subscriber_no)
REFERENCES mc_subscribers(mc_subscriber_no) DEFERRABLE

Dropping the foreign key failed:

vodlive_slave1=# alter table mc_today_xtns drop constraint
fk_mc_today_xtns_mc_subscriber ;
ERROR:  "pk_mc_subscribers" is an index

I think what is happening is that slony has removed the triggers for
the foreign key on mc_subscribers:

voddev_slave1=# select relname, pg_trigger.* from pg_trigger join
pg_class on tgrelid = pg_class.oid where relname = 'mc_subscribers' ;
    relname     | tgrelid  |         tgname          |  tgfoid  |
tgtype | tgenabled | tgisconstraint | tgconstrname | tgconstrrelid |
tgdeferrable | tginitdeferred | tgnargs | tgattr |    tgargs
----------------+----------+-------------------------+----------+--------+-----------+----------------+--------------+---------------+--------------+----------------+---------+--------+---------------
 mc_subscribers | 28724489 | _vodslony_denyaccess_65 | 45139590 | 31 |
t         | f              |              |            0 | f      | f 
            |       1 |        | _vodslony\000

On the master, there are triggers for all of the foreign key
constraints which point to mc_subscribers.

I would think removing the foreign key triggers on the slaves is the
wrong thing to do.  Should we remove the foreign keys on the slave
databases?

 - Ian