Jeff Amiel jamiel at istreamimaging.com
Thu Apr 3 11:14:23 PDT 2008
I added a new replication set recently with a few new tables and sequences.

Today I started getting error  "duplicate key violates unique 
constraint" when slony was trying to insert into my two subscriber nodes.
I looked and sure enough..there was already an entry in table with the 
same primary key as the one it was trying to insert...

I thought maybe I had not replicated the sequence or something 
silly...but that wasn't the case.
I chalked it up to a really bad and confusing week and decided that I 
would just drop the table from replication and then re-add it
(table has mostly transient data that is deleted nearly as quickly as it 
is inserted but there are SOME long term records ...and in this case 
just one so resyncing that table would be no great hardship)

I did  a set drop table and set drop sequence (separately for some 
reason) on the table and it's correlated sequence....and yet I still was 
getting the duplicate key error.

At that point I decided to drop the data from the table in the 
subscriber nodes....(delete from yadda yadda) but got the 'permission 
denied to do bad things on subscriber node' error.

Hmmm, I thought.....
well...so I circumvented by dropping and re-adding the table in both 
subscriber nodes.

Ick..things got worse.

Now slony just keeps 'restarting' on both subscriber nodes with error 
like this:

ERROR  remoteWorkerThread_1: "begin transaction; set transaction 
isolation level serializable; lock table 
"_istream_replication_cluster".sl_config_lock; select 
"_istream_replication_cluster".setDropTable_int(103);notify 
"_istream_replication_cluster_Event"; notify 
"_istream_replication_cluster_Confirm"; insert into 
"_istream_replication_cluster".sl_event     (ev_origin, ev_seqno, 
ev_timestamp,      ev_minxid, ev_maxxid, ev_xip, ev_type , ev_data1    ) 
values ('1', '3115555', '2008-04-03 12:22:15.552003', '629198517', 
'629198538', '''629198517'',''629198534''', 'SET_DROP_TABLE', '103'); 
insert into "_istream_replication_cluster".sl_confirm  (con_origin, 
con_received, con_seqno, con_timestamp)    values (1, 4, '3115555', 
now()); commit transaction;" PGRES_FATAL_ERROR ERROR:  Slony-I: 
alterTableRestore(): Table with id 103 not found
CONTEXT:  SQL statement "SELECT  
"_istream_replication_cluster".alterTableRestore( $1 )"
PL/pgSQL function "setdroptable_int" line 52 at perform


oops...of course I have no table 103....at least not any more.

Now what....?
How do I either fool the system into thinking the table is their so it 
can remove it...or clean up these stale sync items for a table that does 
not exist so I can re-add this rougue table and sequence again from scratch?

What SHOULD I have done instead of the fiasco that I created?


Any help would be appreciated.








More information about the Slony1-general mailing list