Richard Yen <dba at richyen.com> writes:
> Hi All,
>
> I've encountered this a few times before in the past, but sometimes
> after I drop a table from replication, I cannot remove them from the
> schema.  I can successfully drop them from the origin database, but
> on the subscriber databases, I encounter some errors, namely, the
> following:
>
> mydb=# begin; drop table new_gm_qm_set;
> BEGIN
> NOTICE:  constraint new_gm_qm_template_qm_set_fkey on table
> new_gm_qm_template depends on table new_gm_qm_set
> NOTICE:  constraint new_gm_qm_set_share_qm_set_fkey on table
> new_gm_qm_set_share depends on table new_gm_qm_set
> ERROR:  "m_user_pkey" is an index
> mydb=# rollback;

Your belief that "they are in a strange state" is indeed correct.

The constraints, on subscriber nodes, get repointed to the primary key
candidate index, and that evidently causes the phenomenon that you're
seeing.

The *right* way to drop a table from replication is to first of all
run the slonik "SET DROP TABLE" command against the table.  

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.
-- 
let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;;
http://linuxdatabases.info/info/slony.html
Epistemology in One Lesson
Reality ruthlessly selects out creatures that embody hypotheses too
inconsistent with reality. Our only choice is whether we participate
by being selected out, or (in Popper's great phrase) by "letting our
ideas die in our stead."
-- Mark Miller