On 7/7/2005 3:31 PM, Joe Markwardt wrote:
> On Thu, 2005-07-07 at 15:18 -0400, Jan Wieck wrote:
>> after reading the entire thread it appears that you attempted to drop
>> the table on the subscriber before the event for removing the table from
>> the set actually propagated to the subscriber. That would be the only
>> chance that the denyaccess trigger is still defined for it and the
>> foreign key triggers are still "parked" on the tables PK index (that's
>> one of the weird things Tom was talking about).
>> 
> 
> That could be I usually check the logs before I make any changes like
> this to make sure my slonik commands have propogated, but I may have
> forgotten this time.  Any idea's on how to fix it other than re-starting
> replication from scratch?

Since the table is still setup for replication and the drop table 
fortunately failed, I would assume that the SET_DROP_TABLE event is 
still sitting in the event queue. So restarting the slon on the 
subscriber should fix it. Or am I missing something here?


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #