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.

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

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

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

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

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.

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