Random Things That Ought To Be Documented Somewhere
---------------------------------------------------------------------------------------------

$Id: randomfacts.txt,v 1.3 2004/10/14 22:03:55 cbbrowne Exp $

These are things that have been noticed that need to be documented.
There should probably be a "How To Set Up a Simple Slony-I Replication
System" document as well as "Advanced Slonying for Master DBAs," and
these should be added to those sorts of documents...

1.  Yes, you CAN "kill -9" slon processes

It's not a particularly evil thing to do...

2.  You can subscribe a node without having started the "slon" process
for that node.

Nothing will start replicating until the "slon" starts up.

3.  No, you don't really need a "node 1".  

In many places, slonik defaults kind of assume that there is one, but
it doesn't HAVE to be there.

4.  A little more about primary keys.

Slony-I NEEDS to have a primary key candidate to work with in order to
uniquely specify tuples that are to be replicated.  This can work out
three ways:

 - If the table has a primary key defined, then you can do a SET ADD
   TABLE on the table, and it'll "just replicate."

 - If the table has NO "unique, not NULL" key, you need to add one.

   There's a slonik command to do that; TABLE ADD KEY.

 - The _third_ case is where the table has one or more _candidate_
    primary keys, none of which are formally defined to be THE primary
    key.

    In that case, you must pick one of them, and specify it in the SET
    ADD TABLE statement.

The use of TABLE ADD KEY should be avoided.

5 I want to update data on any of my servers, and have it propagate
  around.

  That case is specifically NOT addressed by Slony-I.  Slony-I _locks_
  all the replicated tables on the subscribers; updates are only
  permitted on the "master" node.

  There are plans for a later Slony-II project to address distributed
  updates; part of the point of Slony-I is to provide the
  "bootstrapping" system needed to get multiple databases "in sync,"
  which is a prerequisite for being able to do distributed updates.

  That still means that distributed updates (e.g. - doing updates at
  other than One Single Master Server Node) is NOT part of the Slony-I
  design.
