It eventually died with:

2010-06-17 17:53:06 EDTFATAL  localListenThread: "select 
"_devel".cleanupNodelock(); insert into "_devel".sl_nodelock values (    
2, 0, "pg_catalog".pg_backend_pid()); " - ERROR:  duplicate key value 
violates unique constraint "sl_nodelock-pkey"

2010-06-17 17:53:06 EDTINFO   slon: shutdown requested
2010-06-17 17:53:06 EDTINFO   slon: notify worker process to shutdown
2010-06-17 17:53:26 EDTINFO   slon: child termination timeout - kill child
2010-06-17 17:53:26 EDTCONFIG slon: child terminated status: 9; pid: 
23878, current worker pid: 23878
2010-06-17 17:53:26 EDTINFO   slon: done
2010-06-17 17:53:26 EDTINFO   slon: exit(0)


Joseph S wrote:
> I'm having a problem with 2.0.4 but it isn't related to the problem I 
> was having with 2.0.3.  I had a table that I kept creating, adding to 
> the slony replication set, and then dropping and starting over.  During 
> this time I wasn't running slony because of the bugs in 2.0.3.  Now that 
> 2.0.4 rc2 is running it got stuck in a loop trying to create this table 
> and failing because it existed already.  I kept dropping the table from 
> my slave until that wasn't a problem anymore but now it is stuck in a 
> loop doing this:
>
>
> ERROR:  Slony-I: alterTableDropTriggers(): Table with id 41 not found
> CONTEXT:  SQL statement "SELECT  "_devel".alterTableDropTriggers( $1 )"
>          PL/pgSQL function "dropset_int" line 18 at PERFORM
> STATEMENT:  select "_devel".dropSet_int(999); insert into 
> "_devel".sl_event     (ev_origin, ev_seqno, ev_timestamp, 
> ev_snapshot, ev_type , ev_data1    ) values ('1', '5000048246', 
> '2010-04-27 18:44:50.666916', '720295:720295:', 'DROP_SET', '999'); 
> insert into "_devel".sl_confirm   (con_origin, con_received, con_seqno, 
> con_timestamp)    values (1, 2, '5000048246', now()); commit transaction;
> LOG:  unexpected EOF on client connection
>
> How can I break it out of this loop?
>
> Steve Singer wrote:
>   
>> Joseph S wrote:
>>     
>>> I can't compile 2.0.4 rc2
>>>
>>> make[2]: *** [scan.o] Error 1
>>> make[2]: Leaving directory 
>>> `/local/download/src/slony1-2.0.4.rc2/src/slony_logshipper'
>>> make[1]: *** [all] Error 2
>>> make[1]: Leaving directory `/local/download/src/slony1-2.0.4.rc2/src'
>>> make: *** [all] Error 2
>>>       
>> This is actually a bug in the distclean rule in slony_logshipper.  Our 
>> policy has been to require bison/flex for cvs builds but to include the 
>> generated files in the tarfiles.  The distclean rule seems to be 
>> deleting the scan.l file.
>>
>> If you install flex you can avoid that error.   We will include those 
>> files in the next tarfile (technically this means we should have a rc3 
>> but I'd like to see what else people find)
>>
>> Thanks
>>
>>     
>>> There is a scan.c under src/slonik/
>>>
>>> Steve Singer wrote:
>>>       
>>>> Joseph S wrote:
>>>>         
>>>>> Should I blow away my old slave database and rereplicate from 
>>>>> scratch?  Or can I just upgrade slony and start it up?
>>>>>
>>>>> Steve Singer wrote:
>>>>>           
>>>>>> I have tagged Slony-I 2.0.4 RC2
>>>>>>
>>>>>> This is like 2.0.4 RC1 plus the memory leak fixes discussed on the 
>>>>>> list.
>>>>>>
>>>>>> http://lists.slony.info/downloads/2.0/source/slony1-2.0.4.rc2.tar.bz2
>>>>>>
>>>>>> It would be nice if people could test it and report back to the list.
>>>>>>
>>>>>>
>>>>>>             
>>>> As long as your test database was in a resonable state the upgrade 
>>>> from a previous 2.0.x release should work fine.  Please report any 
>>>> issues you encounter
>>>>
>>>>
>>>>         
>>>>>>   
>>>>>>             
>>>>> _______________________________________________
>>>>> Slony1-general mailing list
>>>>> Slony1-general at lists.slony.info
>>>>> http://lists.slony.info/mailman/listinfo/slony1-general
>>>>>           
>>>>         
>>     
>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>