On Thu, May 05, 2005 at 03:21:40PM +0100, Peter Wilson wrote: > Why is this documentation on 'Christoper B. Browns homepage rather than > the Slony web pages? The 'official' Slony documentation I had available > was at : > http://gborg.postgresql.org/project/slony1/genpage.php?howto_idx > > and it *really* didn't help with the problems I had. I think it's already been acknowledged that the 1.0.5 release's documentation wasn't as comprehensive as people liked; but that is, as has also been noted, because nobody had run into the problems you had yet (i.e. the documentation was as complete at release time as the users had been able to make it). Nevertheless, it is not true that the documentation isn't on the slony pages. By my count, including the header bar, the "admin guide" is the 10th link on the page. It's near the top. These updated docs are also in the currently-beta version of the software. (I don't want to get into a flamewar over this; I just think it's unfair to claim the docs aren't there.) > Having now taken a look at the documentation you reference, it's still > not wonderfully comprehensive. The problem I had was that despite the > fact that my tables had primary keys the Slony configuration refused to > recognise them. The documentation says simply that primary or candidate > primary keys are a requirements. This is also not true. The documentation for SET ADD TABLE tells you that there is a KEY option to tell slonik what the key field is. Automatic detection won't always work, because not all "primary keys" are so noted in a PostgreSQL database. What is worth mentioning, though, is that Slony is not as simple to set up as some of the alternatives, like dbmirror. This is because items like controlled switchover, failover, cascading, target promotion, and log shipping are all designed-in features of Slony. The same is not true of dbmirror, or erserver. My experience tells me that such features are very hard to add in retrospect. Indeed, the very reason Afilias sponsored development of Slony was that we concluded the features we wanted could be more easily built from the ground up than added to any of the alternatives we then had available. (This isn't to say everybody should use Slony; just that it's important to realise that additional features come at the cost of additional complexity. My bet is that anyone really needing high availability will end up needing some of those additional features.) A -- Andrew Sullivan | ajs@xxxxxxxxxxxxxxx When my information changes, I alter my conclusions. What do you do sir? --attr. John Maynard Keynes ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
