Sorry, I think we're not on the same page re. this issue.

> The *right* way to drop a table from replication is to first of all
> run the slonik "SET DROP TABLE" command against the table.
>
I have in fact run SET DROP TABLE on the table prior to attempting to  
drop the table from schema.  The table (new_gm_qm_set) doesn't show  
up in sl_table:

mydb=# select * from _myslony.sl_table where tab_relname =  
'new_gm_qm_set';
tab_id | tab_reloid | tab_relname | tab_nspname | tab_set |  
tab_idxname | tab_altered | tab_comment
--------+------------+-------------+-------------+--------- 
+-------------+-------------+-------------
(0 rows)

> When that is processed, on the origin, the "logtrigger" trigger gets
> removed.
> When that is processed, on subscribers, the "denyaccess" trigger gets
> removed, and the constraints get fixed up.
>
The logtrigger on the desired table for deletion (new_gm_qm_set ) is  
already gone:
mydb=# \d new_gm_qm_set;
                              Table "public.new_gm_qm_set"
      Column     |  Type   |                         Modifiers
----------------+--------- 
+------------------------------------------------------------
id             | integer | not null default nextval 
('new_gm_qm_set_id_seq'::regclass)
owner          | integer |
[blah blah blah...]
Indexes:
     "new_gm_qm_set_pkey" PRIMARY KEY, btree (id)
Foreign-key constraints:
     "new_gm_qm_set_owner_fkey" FOREIGN KEY ("owner") REFERENCES  
m_user(id)

However, when I go to delete my desired table (new_gm_qm_set), it  
complains about another table:
mydb=# begin; alter table new_gm_qm_set drop constraint  
new_gm_qm_set_owner_fkey;
BEGIN
ERROR:  "m_user_pkey" is an index



--Richard