Andrew,

Thank you very much for the detailed response. In my case, the table is 
not even part of a replication set, but I do need to bulk-load data into 
the table in question on a regular basis...or at least I think I do. 
We're that to fail, my little startup (http://www.altosresearch.com/) 
would go bye-bye in a hurry ;)

This leads me to believe that I've been looking at my problem from the 
wrong direction. The primary product we sell are PDF reports of real 
estate market analytics. Part of what we do is gather data on real 
estate listings from a variety of sources. This data collection work is 
spread across several servers, all of which populate a non-replicated 
tabled (listing_entry). Upon completion, I export the data collected on 
each server and import that into the other two servers. Once completed, 
each of the three servers then has a complete set of listing_entry rows 
for that week.

What would instead be ideal (and more automated/less manual work) would 
be a system in which the data in this 'listing_entry' table was 
automatically dispersed to each of the other nodes in the cluster:

collection-server-1
collection-server-2
    .
    .
    .
collection-server-n

For example, a new listing_entry row inserted on collection-server-1 
would then be replicated to the listing_entry tables on 
collection-server-2 through collection-server-n. This calls for more of 
a multi-master/multi-slave approach, unlike the 
single-master-multi-slave design that slony supports.

I have resisted implementing this at the application level, hoping to 
come across a tool that would allow me to do this bi-directional 
synchronization. Does any such beast exist, or is this ulimately a 
do-it-yourself job?

-jason

Andrew Sullivan wrote:
> emphasise that this cannot be used _regularly_ on active tables. 
> This is not the solution for a daily bulk load into an active table,
> is all.  The perhaps alarmist disclaimers are there partly because