Switch branches/tags
Find file
Fetching contributors…
Cannot retrieve contributors at this time
122 lines (92 sloc) 4.91 KB
Building and Installing Slony-I
Slony-I 2.0 currently supports PostgreSQL 8.3.x, 8.4.x and it has been
built and tested against 9.0 beta2.
Note that earlier major versions supported earlier PostgreSQL
- 1.0 and 1.1 supported versions back to the 7.3.x series
- 1.2 supported versions 7.4, 8.0, 8.1, 8.2, 8.3 and 8.4
If you require support for earlier versions of PostgreSQL, please
avail yourself of an earlier Slony-I release.
Important Configuration parameters
Slony-I normally needs to be built and installed by the same user that
owns the PostgreSQL binaries. The installation target must be
identical to the existing PostgreSQL installation particularly in view
of the fact that several Slony-I components represent libraries and
SQL scripts that need to be in the PostgreSQL lib/ and share/
On certain platforms (AIX and Solaris are known to need this),
PostgreSQL must be configured with the option --enable-thread-safety
to provide correct client libraries.
The location of the PostgreSQL source-tree was specified with the
configure option --with-pgsourcetree=<dir>. As of 1.1, this configure
option no longer exists, instead, locations of database components are
specified individually, such as:
--with-pgconfigdir=<dir> Location of the PostgreSQL pg_config program.
--with-pgbindir=<dir> Location of the PostgreSQL postmaster.
--with-pgincludedir=<dir> Location of the PostgreSQL headers.
--with-pgincludeserverdir=<dir> Location of the PostgreSQL server headers.
--with-pglibdir=<dir> Location of the PostgreSQL libs.
--with-pgpkglibdir=<dir> Location of the PostgreSQL pkglibs. E.g.
--with-pgsharedir=<dir> Location of the PostgreSQL share dir. E.g. postgresql.conf.sample
All you should need to specify is the first of those locations, namely
--with-pgconfigdir=/path/to/pg_config/bin; the others may be inferred
based on the output of pg_config.
After running configure, you may wish to review the file
"" to ensure it is looking in the right places for all of
the components. If you failed to specify some of those locations, you
may discover that your system fills in some surprising values...
Files Installed
The main list of files installed within the PostgreSQL instance is:
* $bindir/slon
* $bindir/slonik
* $libdir/slony1_funcs$(DLSUFFIX)
* $datadir/slony1_base.sql
* $datadir/slony1_base.v83.sql
* $datadir/slony1_funcs.sql
* $datadir/slony1_funcs.v83.sql
The .sql files are not fully substituted yet. And note that all of
the "v??.sql" .0 files get installed as part of every Slony-I
installation, irrespective of its version. The slonik admin utility
does namespace/cluster substitutions within the files, and loads those
files when creating replication nodes. At that point in time, the
database being initialized may be remote and may run a different
version of PostgreSQL than that of the local host.
At the very least, the shared objects installed in the $libdir
directory must be installed onto every computer that is supposed to
become a Slony node. (Other components may be able to be loaded
remotely from other hosts.)
altperl Administration tools
If you wish to have the "altperl" administration tools available, you
need to specify the "--with-perltools=somewhere" option.
Building Documentation - Admin Guide
There is an extensive "Administrator's Guide" containing what wisdom
has been discovered and written down about the care and feeding of
A pre-built copy of the "admin guide" should be readily available,
either in the form of a separate tarball nearby, or in the directory
Building Slony-I for use with Packaged PostgreSQL Binaries
If you are building Slony-I against a prepackaged binary install of
PostgreSQL as provided in RPM or .deb packages, you very likely need
to install an additional "postgresql-dev" package which contains the
PostgreSQL #include files.
If you are looking for what software dependancies there are, it may be
useful to look at the file redhat/slony-I.spec to see what
dependancies they point to. There is also a .spec file around for
SuSE. If you have difficulties building on distributions based on
either Red Hat or SuSE's distributions, the ".spec" files may be quite
useful to help puzzle things out.
On RHAS/RHEL/Centos, people have frequently reported problems relating
to missing Kerberos #include files; apparently the use of OpenSSH for
authentication draws in a dependancy on Kerberos that isn't
automatically detected. You may need to add an -I path for
/usr/kerberos/include; see slony1.spec for more
On Debian, there is now an official package; see
<> for more details.