I've gone through the default slon.env file and added a lot of documentation 
to help new users set it up.  I've also changed the defaults to be more 
inline with the various Linux and *BSD systems I've seen (admittedly not 
many of the latter).

This assumes that my previous $CLUSTER_NAME patch has been applied.

I've just attached the new file instead of a patch since I essentially 
changed every line.

-- 
Steve Simms <steve at deefs.net>
http://www.deefs.net
-------------- next part --------------
# $Id: slon.env,v 1.8 2005/01/26 19:42:25 darcyb Exp $
# Author: Christopher Browne
# Copyright 2004 Afilias Canada

# Keeping the following three lines for backwards compatibility in
# case this gets incorporated into a 1.0.6 release.
#
# TODO: The scripts should check for an environment variable
# containing the location of a configuration file.  That would
# simplify this configuration file and allow Slony tools to still work
# in situations where it doesn't exist.
#
if ($ENV{"SLONYNODES"}) {
    require $ENV{"SLONYNODES"};
} else {

    # The name of the replication cluster.  This will be used to
    # create a schema named _$CLUSTER_NAME in the database which will
    # contain Slony-related data.
    $CLUSTER_NAME = 'replication';

    # The directory where Slony should record log messages.  This
    # directory will need to be writable by the user that invokes
    # Slony.
    $LOGDIR = '/var/log/slony';

    # The directory containing the slon and slonik executables
    $SLON_BIN_PATH = '/usr/local/pgsql/bin';

    # (Optional) If you would like to use Apache's rotatelogs tool to
    # manage log output, uncomment the following line and ensure that
    # it points to the executable.
    #
    # $APACHE_ROTATOR = '/usr/local/apache/bin/rotatelogs';

    # Which node is the default master for all sets?
    $MASTERNODE = 1;

    # Include add_node lines for each node in the cluster.  Be sure to
    # use host names that will resolve properly on all nodes
    # (i.e. only use 'localhost' if all nodes are on the same host).
    # Also, note that the user must be a superuser account.

    add_node(node     => 1,
	     host     => 'server1',
	     dbname   => 'database',
	     port     => 5432,
	     user     => 'postgres',
             password => '');
    
    add_node(node     => 2,
	     parent   => 1,
	     host     => 'server2',
	     dbname   => 'database',
	     port     => 5432,
	     user     => 'postgres',
             password => '');
    
    add_node(node     => 3,
	     parent   => 1,
	     host     => 'server3',
	     dbname   => 'database',
	     port     => 5432,
	     user     => 'postgres',
             password => '');
    
}

# Keeping the following three lines for backwards compatibility in
# case this gets incorporated into a 1.0.6 release.
#
# TODO: The scripts should check for an environment variable
# containing the location of a configuration file.  That would
# simplify this configuration file and allow Slony tools to still work
# in situations where it doesn't exist.
#
if ($ENV{"SLONYSET"}) {
    require $ENV{"SLONYSET"};
} else {

    # The first ID to use for tables and sequences that are added to
    # the replication cluster.  This must be unique across the
    # cluster.
    # 
    # TODO: This should be determined automatically, which can be done
    # fairly easily in most cases using psql.  create_set should
    # derive it, and give an option to override it with a specific
    # value.
    $TABLE_ID    = 1;
    $SEQUENCE_ID = 1;

    # This array contains a list of tables that already have primary
    # keys.
    @PKEYEDTABLES=(
		   'table1',
		   'table2'
		   );

    # For tables that have unique not null keys, but no primary key,
    # enter their names and indexes here.
    %KEYEDTABLES=(
		  'table3' => 'index_on_table3',
		  'table4' => 'index_on_table4'
		  );

    # If a table does not have a suitable key or set of keys that can
    # act as a primary key, Slony can add one.
    #
    # Note: The Slony development team does not recomment this
    # approach -- you should create your own primary keys instead.
    @SERIALTABLES=(
		   'table5'
		   );

    # Sequences that need to be replicated should be entered here.
    @SEQUENCES=(
		'sequence1',
		'sequence2'
		);

}

# Please do not add or change anything below this point.
1;