On 7/7/2005 2:44 PM, Joe Markwardt wrote:

> On Thu, 2005-07-07 at 12:21 -0400, Jan Wieck wrote:
>> On 7/7/2005 11:54 AM, Joe Markwardt wrote:
>> > Greetings all, 
>> > 	I'm posting this question here per suggestion from Tom Lane on the
>> > postgres-general mailing list.
>> > 
>> > The thread on the postgres list:
>> > http://archives.postgresql.org/pgsql-general/2005-07/msg00126.php

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).


Jan

>> > 
>> > 	Basically what lead up to this was I needed to drastically change the
>> > structure of the pl_inventory_analyzer_files_table so I dropped the
>> > table from replication, dropped and recreated it on the provider with no
>> > problems, went to drop and recreate it on the subscriber and got the
>> > error in the subject.
>> > 
>> > 	So I guess what I'm looking for is how to fix this error so I can drop
>> > the table, recreate it and get on with life. Hopefully without dropping
>> > the entire subscriber node and re-subscribing.  Course if I have to do
>> > that I may as well make the jump from 1.05 to 1.1 at the same time :)
>> 
>> Did you just throw the DDL via psql at the databases or did you do it 
>> with the appropriate slonik command?
> 
> First I ran a slonik script to remove the table from the replication set
> using the SET DROP TABLE slonik command.  After that I then ran "DROP
> TABLE pl_inventory_analyzer_files;" by hand from the psql command line,
> first on the database server that was the provider, then on the server
> that was the subscriber.  I thought that once I had successfully ran the
> "SET DROP TABLE" that I could then modify the table at will.  Did I
> forget or misinterpret something?
> 
>> http://gborg.postgresql.org/project/slony1/genpage.php?slonik_commands#stmt_ddl_script
>> 
>> In case you didn't know about execute script, you probably are best off 
>> to use "uninstall node" for all nodes and reinstall slony from scratch.
> 
> I use execute script for all minor changes to tables that are in the
> replication set.  If its a major change ( like this one was, basically
> changing over half the columns in the table, requiring a reload of the
> data in this table )  I will usually follow the procedure outlined
> above, then re-create the table, use a temp set and merge set to get
> replication going on the new table, then load the data.  It has worked
> successfully so far.
> 
> Thanks
> 	Joe
> 
>> 
>> Jan
>> 
>> > 
>> > Thanks for your time, 
>> > 	Joe
>> > 
>> > _______________________________________________
>> > Slony1-general mailing list
>> > Slony1-general at gborg.postgresql.org
>> > http://gborg.postgresql.org/mailman/listinfo/slony1-general
>> 
>> 


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