Jan Wieck wrote:

> 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?

Ah, but if some event BEFORE that one keeps failing, it will never get
around to the SET_DROP_TABLE.

Suppose there is data to be replicated into that table before  it is
dropped; that would Cause A Problem...