On Sun, 5 Nov 2006, cbbrowne at ca.afilias.info wrote:

>> On Sun, 5 Nov 2006, Andrew Sullivan wrote:
>>
>>> On Sat, Nov 04, 2006 at 12:03:48PM -0800, Jeff Frost wrote:
>>>> Interesting.  This table has never been part of the subscription set,
>>>> would it
>>>> have added these catalog manipulations anyway?
>>>
>>> Sort of.  Likely, something has collided.  The general rule is, I
>>> think, very clear: no DDL at all if you don't do it through EXECUTE
>>> SCRIPT.
>>
>> This was definitely what was needed to drop the table in question.
>>
>> Maybe we can add this to the doc or the FAQ?  I certainly would not have
>> thought I needed to use execute script to drop non-replicated tables based
>> on
>> the docs in adminguide/ddlchanges.html.  Maybe I didn't look hard enough
>> in
>> the docs?
>
> You looked hard enough; this scenario is a bit surprising...
>
> If we can characterize it a bit better, that would be nice...

Tell me what more I can do to describe it and I'll be happy to.  The basic 
gist of it was this:

I had a DB with some subscribed tables.  All of the summary_* tables were not 
replicated.  As expected, I was able to drop the summary_target table on the 
master, but when attempting to drop it on the slave (or drop any of the 
foreign key constraints it had) I would receive an error such as:

error: markets_pk is an index

markets_pk is (as you might guess) the primary key on the markets table, which 
is referenced by a fkey in summary_target.

If I passed the DROP TABLE summary_target; through EXECUTE SCRIPT, it 
magically worked.  I was quite surprised..I was actually thinking maybe there 
was an index corruption problem or something else of the like.  I would have 
never guessed I need to EXECUTE SCRIPT to drop an unsubscribed table even 
though it has fkeys that point to replicated tables.


-- 
Jeff Frost, Owner 	<jeff at frostconsultingllc.com>
Frost Consulting, LLC 	http://www.frostconsultingllc.com/
Phone: 650-780-7908	FAX: 650-649-1954