Greg,

Due to performance reasons we are using a COPY command now (INSERT INTO was just for testing).  With some of our tables having 5 milling + records we want it to go as fast as.  You are correct in assuming it is a --data-only dump.  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;

I have had the data replicate correctly once when loading the data for a single table using COPY, but not since then.  I get the following statistics for the slave node.

Last event - 465
Last event timestamp - 2/17/2012 10:49:46
Last acknowledged - 56
Last ack timestamp - 2/17/2012 09:20:05
Last response time - 0.016 s
Outstand acks - 409
No ack for - 01:29:41.127
Hanging event - 57
Command - SYNC

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.

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: Friday, February 17, 2012 10:45
To: Shaun McCloud
Cc: slony1-general at lists.slony.info
Subject: Re: [Slony1-general] Slony not replicating changes

On Fri, Feb 17, 2012 at 02:30:24PM +0000, Shaun McCloud wrote:
> My code is not creating the dump with --disable-triggers.

There are very few things it could be then. If it works in other situations, that means the Slony triggers are enabled and working on the tables, which rules out one possibility. Open the pg_dump output in a text editor and make sure it is using INSERTs, and that there is nothing funny at the top of the script (e.g. changing the session_replication_role or disabling triggers). Also, I'm assuming this is a --data-only pg_dump? Finally, make sure your are loading the output into the correct database and that no search_path/schema tweaks could be affecting things.

If all else fails, see if you can create a simple test case (e.g. 
pg_dump a single small table) and post it here.

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