Consider the following configuration:

Cluster #1: prod_backup_cluster: Used to replicate all tables and all data 
from my the 'production_db' database on srv1 to the 
'prod_backup' database running on srv3:

srv1:production_db --prod_backup_cluster--> srv3:prod_backup

Cluster #2: prod_trxn_cluster: Used to replicate certain customer 
transaction-related tables:

srv1:production_db --prod_trxn_cluster---> srv3:prod_trxns

Question #1: What are the chances that the two slony processes, each of 
which will be reading from the same master database (srv1:production_db), 
will find themselves in a deadlock situation when the application makes 
updates to the data hosted in srv1:production_db?

Question #2: What would be the advantages of making this a single cluster 
with three nodes and two sets (one set coverall all tables for the 'backup' 
and another set of just the transactional tables)?

Now, we add a third cluster to the configuration, just to make everything a 
bit more complicated:

Cluster #3: stats_cluster: Used to replicate the results of a large number 
of statistical calculations from srv2:stats_db to srv1:production_db:

srv2:stats_db --stats_cluster--> srv1:production_db

The result of this will be that data from a single table (we have a table 
called 'city_summary', for example) will go from srv2 -> srv1 (via 
stats_cluster), then from srv1 -> srv3 (via prod_backup_cluster).

Question #3: There are times where the 'city_summary' table, residing on 
srv1:production_db will be written to with data originating from 
srv2:stats_db while at the same time being replicated to srv3:prod_backup. 
All of this will happen using three distinct slony clusters. Will I end up 
in a state of continual deadlock?

Question #4: Am I totally insane, or just a big dolt?

Thanks,
Jason