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
>
> 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 don't think your problem has anything to do with your intent of
"circularity."

After all, you haven't gotten around to asking Slony-I to replicate
anything at all in the later instance; the error message is consistent
with slonik trying to set up the namespace and stored procedures, and
"something breaking."  That takes place *much* earlier than when any
data starts replicating.

What you need to do is to take a peek at the PostgreSQL logs for the
instance where that failure took place, and see why it encountered the
"fatal error."

It is not at all clear where that broke...

I have a question as to what you intend to do in this...

Do you plan to have "rep_schema2" take updates from any of the same
tables (on satellite_cpu/slave_db) which are being replicated in
"rep_schema1"?

If so, that'll definitely break.

On subscribers (such as the "satellite" host), Slony-I puts a trigger on
each of the replicated tables calling a function called deny_access(),
which prevents updates from being applied to replicated tables aside
from via replication.

If you were planning to update those tables on "satellite", and
propagate them back, you'll find that doesn't work.  The deny_access
functions will stymie attempts to update the tables on the subscriber.