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
[EMAIL PROTECTED] 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
[email protected]
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. #
#================================================== [EMAIL PROTECTED] #
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
