I have tried to migrate from PostgreSQL 8.3 and its associated version of Slony to PostgreSQL 8.4 and Slony 2.0.4.  However, even following the directions at http://www.pgadmin.org/docs/dev/slony-example.html I cannot get any data to replicate, the slave node(s).  Everything appears to work great and according to the steps it should be working.  But the slave node(s) never get a Replication Set and the associated data in it.  Does anyone know of a tutorial similar to http://www.enterprisedb.com/resources-community/tutorials-quickstarts/all-platforms/how-setup-slony-i-replication-postgres-plus for Slony 2.0.4?

Shaun McCloud – Associate Software Developer
Geo-Comm, Inc
601 W. Saint Germain St., Saint Cloud, MN 56301
Office: 320.240.0040 Fax: 320.240.2389 Toll Free: 888.436.2666
click here to visit www.geo-comm.com
 
 Think before you print!
Microsoft Certified Desktop Support Technician (MCDST) 
Do or do not, there is no try.
    -Yoda


-----Original Message-----
From: Greg Sabino Mullane [mailto:greg at endpoint.com] 
Sent: Sunday, February 19, 2012 06:41
To: Shaun McCloud
Cc: slony1-general at lists.slony.info
Subject: Re: [Slony1-general] Slony not replicating changes

On Fri, Feb 17, 2012 at 04:52:06PM +0000, Shaun McCloud wrote:
> Before the first COPY statement the dump contains the following.
> 
> SET client_encoding = 'UTF8';
> SET standard_conforming_strings = off; SET check_function_bodies = 
> false; SET client_min_messages = warning; SET escape_string_warning = 
> off; SET search_path = sde, pg_catalog;

Nothing unusual there.

> I have had the data replicate correctly once when loading the data for 
> a single table using COPY, but not since then.

Well I cannot see any other obvious problems, so I would suggest seeing if you can get that single table COPY pg_dump to work again, then expand the scope (if working) or narrow the scope (if not).

> Also, I'm not sure if it matters; but we are using two engines for one 
> Slony-I service.  One for mostly static data and one for data that can 
> change quite often.  Each engine has its own DB and the data that can 
> change quite often is always replicating fine, but it is always edited 
> using ESRI's Arc Map at some point in the process.

Ah, that could certainly be a factor - can you explain the layout a bit more to the list?

--
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 0x14964AC8