Just a warning, this post is kinda long :-)

On Fri, 2005-07-08 at 11:01 -0400, 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?

I'm not sure we're on the same page here.  It sounds to me like you may
be talking about the pl02_status_table, which I am not trying to drop
and is still being replicated.  I am trying to drop the
pl_inventory_analyzer_files_table.  If I understand what you're saying
there should be some residual slony triggers on the pl_inventory...table
if the SET DROP TABLE failed.    

This is pl_inventory_analyzer_files_table as it exists on the subscriber
node right now.

pl=# \d pl_inventory_analyzer_files_table
                                        Table
"public.pl_inventory_analyzer_files_table"
    Column     |            Type             |
Modifiers
---------------+-----------------------------+-----------------------------------------------------------------------------------
 file_id       | integer                     | not null default
nextval('public.pl_inventory_evaluator_files_file_id_seq'::text)
 name          | character varying(150)      | not null
 status_id     | integer                     |
 date_uploaded | timestamp without time zone | default now()
 zip           | boolean                     | not null default true
 search_types  | character varying(20)       | not null
 delimited_by  | character varying(10)       | not null default
'TAB'::character varying
 uid           | integer                     |
 stored_name   | character varying(150)      | not null
Indexes:
    "pl_inventory_evaluator_files_pkey" primary key, btree (file_id)
Foreign-key constraints:
    "$1" FOREIGN KEY (status_id) REFERENCES pl02_status_table(status_id)
    "$2" FOREIGN KEY (uid) REFERENCES pl02_user_login_table(uid)

pl=# select oid from pg_class where
relname='pl_inventory_analyzer_files_table';
    oid
-----------
 438095488
(1 row)

pl=# select * from "_T1".sl_table where tab_reloid = 438095488;
 tab_id | tab_reloid | tab_set | tab_idxname | tab_altered | tab_comment
--------+------------+---------+-------------+-------------+-------------
(0 rows)

pl=#

To me this looks like the SET DROP TABLE succeeded, although I don't
know enough to say that with authority.  

Now when I try to drop the pl_inventory...table I get the error in the
subject line.  After talking with Tom it looks like there was some
funkyness with the oids in the pg_trigger system table, involving
foreign key "$1", namely that it appears to reference a non-existant
oid. But I could be misunderstading things as well. 

As far as re-starting the slon daemon on the subscriber, that was done
when I restarted the postgres daemon on the subscriber, which I had
tried even before I started the thread on the pgsql-general list, I will
happily try it again if you still think it will work, I just wanted you
to know that I had done it once already.  If you need any more
information or have any other suggestions let me know.

Thanks for your time, 
	Joe