See below

----- Original Message ----
> From: Craig James <craig_james at emolecules.com>
> To: slony1-general at lists.slony.info
> Sent: Friday, 4 April, 2008 7:09:24 PM
> Subject: [Slony1-general] Abandoning Slony (was: drop-set/create-set, causes  "node -1 not found")
> 
> Glyn Astill wrote:
> 
> > I had a similar scenario a few months ago and never managed to figure
> > out what happened. Nobody could tell me what the node -1 was all about...
> > 
> > I'd love to know if you  get to the bottom of it.
> 
> Yes, I just now got to the bottom of it.  I realized that Slony is not high 
> enough quality to use in a production environment, and I'm abandoning it until 
> some time in the future when it has matured a bit more.
> 
> This is just the last straw.  I really hate to be critical of any open-source 
> project, because I genuinely appreciate everyone's hard work.  But in the end, 
> Slony has proved to be more trouble that it is worth.  It simply doesn't get the 
> job done reliably.
> 
> It's clear to me that Slony's developers are focused on features, and have not 
> paid enough attention to the user experience.  It's a classic case where the 
> developers, who are experts in their own technology, don't realize just how 
> difficult their product is for the mainstream user.
> 
> * Slony's configuration is like programming in FORTRAN or assembly language in 
> 1966.  There is no reason why Slony should need anything more than a set's name 
> and the table's names that belong to the set.  Computers are good at numbering 
> things, why should I have to?  It takes DAYS to learn how to create a Slony 
> configuration, and it is only achieved through lots of trial and error.

Really? I found the slony docs quite good to be honest, and the slonik language is there to make it flexible.
How you manage to compare slonik scripts to fortran is beyond me, and from that comment I can only guess you've never touched any form of assembly.

> 
> * It is trivially easy to DESTROY an entire database with Slony.  All you have 
> to do is a simply typo, reversing node 1 and node 2, and Slony will, with no 
> further warning, truncate every table in your master database.  There is no way 
> to say, "This is the MASTER, no matter what else I say, never mess with it."  
> This should be a fundamental concept in Slony, but is not.  This is particularly 
> serious, given that Slony expects to connect as the super-user, so you can't 
> (for example) use a guest account that has no write priviliges, which would be 
> the sensible approach.  Slony really needs two users: The super user (during 
> configuration only), and the operational user (during normal operation), and 
> these should be set separately for the master and slaves..
> 

Hmm, slonik has proved to be very forgiving with any typos like that for me. If something is wrong then it generally doesn't run the script. However you can get yourself into a mess if you're not careful to wait for certain things to complete, in my opinion it could do with a little brushing up here. I also recently made a bit of a mess by adding a trigger onto a slave database, then trying to drop the table without bringing it out of the cluster - I still need to sort this.


> * Slony's configuration files can contain errors that are only detected after 
> many hours, even days, of operation have elapsed. This happened to me yesterday: 
> 14 hours after an initial copy-set operation started, it reported that one of 
> the slave tables was missing its primary key, something it could have reported 
> when the cluster was created.  And often when the error is discovered, the only 
> recourse seems to be to uninstall the Slony schema, and restart from ground 
> zero.
>

Afaik if theres no primary key on the table slony will create what it needs?
 
> * Slony can encounter errors from which there is no recovery, except to blow off 
> the system and start over.  Such as the one I'm facing right now.
>

In the aforementioned shagged scenario, I can agree that I had to recreate the slony cluster here to get our of a similar problem - and I can see how it could be a big problem. But honestly - since I read the docs better and ran the scripts ONLY as described in the docs, I've yet to have another big problem.

> 
> * Almost every serious error I've encountered has resulted in a meaningless 
> error message.  The only recourse is to post a question on this forum, and wait 
> for an answer.  Developers have been very friendly and helpful, but the point 
> is, I shouldn't have to come here for EVERY problem.  Take this particular 
> problem, "node -1 not found in runtime configuration."  In the exact spot of 
> code that generated that message, the developer who wrote that code KNEW what 
> was going on.  What operation was being tried?  What set is being copied?  What 
> generated this event?  This information is available somewhere, but IS NOT 
> REPORTED TO THE USER.  This seems to be the rule, not the exception, in my 
> experience with Slony, and it demonstrates a lack of attention to the quality of 
> the user experience.  There is never an excuse for not telling the user 100% of 
> the information that is known when an exception occurs.

I've seen worse in commercial products. But must agree I thought the same about the -1 thing - Surely someone at affilias has to know how we end up with that?

> 
> Or take this example, that I reported on 4/2/2008:
> 
>     ERROR: Slonik version: 1.2.13 != Slony-I version in PG build 1.2.9
> 
> What's the critical missing information here? WHICH NODE NUMBER IS REPORTING 
> THIS???  The developer who wrote this code KNEW which node generated the 
> problem, but didn't put that information into the error message, which cost me, 
> and Jeff Frost (who helped my diagnose the problem), about 4 hours of wasted 
> time.  This seems to be the rule, rather than the exception, in the way Slony is 
> coded.
>

Bloomin heck! How many nodes have you got!
 
> Slony is like a really fast race car.  The drivers are justifiably proud that it 
> is a very fine machine, that their machine is REALLY fast.  But if you want to 
> get to the grocery store, you're better off to take the family car, or even a 
> horse and buggy, because if you take the race car to the grocery store, you may 
> be hungry several times each week.  And if you have a critical situation, like 
> someone is sick, the race car might get them to the hospital very quickly 
> indeed.  But there's an equally good chance the sick patient would die by the 
> side of the road waiting for the the race car's team to repair the engine.
> 
> So, best wishes to the Slony team, and keep up the good work.  If my comments 
> seem harsh, it's because I care: I wouldn't even bother if Slony was junk.  It's 
> a great idea, and most of Slony is well conceived and well executed.  I hope 
> that my comments will be take as constructive criticism.  I hope to be back in a 
> few years when you've made more progress.
> 
> Regards,
> Craig
> 
> 
> 
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
> 




      ___________________________________________________________ 
Yahoo! For Good helps you make a difference  

http://uk.promotions.yahoo.com/forgood/