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:[email protected]]
Sent: Friday, February 17, 2012 10:45
To: Shaun McCloud
Cc: [email protected]
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 [email protected]
End Point Corporation
PGP Key: 0x14964AC8
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
