Karl Lehenbauer wrote:
> Hey...
> 
> We have been running slony reasonably effectively for a couple of years 
> now.  We're on PostgreSQL 8.3, FreeBSD, Slony 2.0.2.
> 
> We had this kind of setup.   A -> B -> C
> 
> B crashed with a weird ethernet problem.  It hung us up real bad so in 
> an emergency we killed all the slon daemons, shutdown postgresql on C 
> and dropped the cluster on A.
> 
> Now we're trying to get back going.  We have this well documented, did a 
> bunch of testing initially, and have done it multiple times successfully 
> in the past.  You know the drill, plus we have a tool to make sure 
> everything has a primary key or an acceptable unique key, generate the 
> slon conf, etc.
> 
> We init the cluster, add the set, add the node, subscribe B to A, and we 
> start getting...
> 
> NOTICE:  Slony-I: log switch to sl_log_2 still in progress - sl_log_1 
> not truncated

Does your initial subscribe (the COPY) ever finish? You don't seem to say.

The logswitch can't happen while there is data that still needs to be 
replicated to the other node.   If your initial copy hasn't finished yet 
then you have rows in sl_log_1 that still need to be replicated, and 
those won't replicate until after the copy finishes.

The other thing that can cause this is if you still have a node 
subscribed setup that ins't running any slons (so it isn't confirming 
events).

> 
> OK, so following the Slony FAQ we killed all of our long-running 
> connections.  No joy.  It never straightens itself out.
> 
> Finally we killed the slon daemons, dropped the schema, then we shut 
> down the database on the primary and start it back up again.  We then 
> went through the procedure to start up B, subscribe it to A, etc, and 
> again we get the error.
> 
> I am sure we shut the database down without a slony schema and with no 
> slon daemons, started it back up, initialized the cluster, added the 
> set, started the slon daemons, but when we subscribe the second node 
> (node 5 by the way), it starts giving that notice.
> 
> We use the slonik tools and I'm pretty familiar with them.
> 
> There can't be any connections with some old cached query plan unless 
> such query plans can survive database server restarts.  We nuked slony, 
> as we've done successfully in the past, and restarted postgres, yet 
> still we get the sl_log_1-not-truncated and the table gets huge and then 
> slow.
> 
> Can anyone hazard a guess as to what's going on and, better yet, what we 
> should do to fix it?
> 
> Regards....
> 
> Karl
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general


-- 
Steve Singer
Afilias Canada
Data Services Developer
416-673-1142