On 6/3/2010 4:14 AM, 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
> 
> OK, so following the Slony FAQ we killed all of our long-running 
> connections.  No joy.  It never straightens itself out.

That message alone isn't a good reason to go into full panic mode and 
tearing down the whole cluster.

Did you give the replica enough time to catch up?

Are long running transactions on the master preventing the log switch to 
succeed?


Jan


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


-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin