On 11/8/2005 5:42 PM, Melvin Davidson wrote:
> I am trying to implement the following replication schema(s)
> 
> _rep_schema1
> HOST = office_cpu           -> SLAVE=satellite_cpu
> DB     = main_db               -> DB       =slave_db
> 
> _rep_schema2
> HOST = satellite_cpu        -> SLAVE=office_cpu
> DB     = slave_db               -> DB       =duplicate_db

This won't work since one and the same table would have to be a 
replicated table in subscriber mode (denying client application updates) 
in one schema and an origin table (allowing client application updates) 
in another.


Jan

> 
> The intent is to have the slave replicate back all
> changes to main_db to the duplicate_db on the master.
> 
> When I execute the script to implement this, it aborts with
> 
> [postgres at slv postgres]$ ./slony_reverse.sh
> <stdin>:105: loading of file /usr/local/pgsql/share//xxid.v74.sql:
> PGRES_FATAL_ERROR ERROR:  current transaction is aborted, commands 
> ignored until end of transaction block
> ERROR:  current transaction is aborted, commands ignored until end of 
> transaction block
> 
> Is there something about a slony slave_db that prevents it from being 
> replicated to another database?
> 
> I do note that _rep_schema2 is created properly on the 2nd HOST 
> (satellite_cpu), but it is not created on the
> SLAVE (office_cpu).
> 
> Does anyone have a short example script for this circular replication?
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #