Andy,

> > We develop a contract management software, we use a Postgre database,
> > which has around 100 tables. Our compnay wants so open 2 more offices(in
> > September) in Europe where the employees will have to work with this
> > management software. And we are looking for a solution that we can
> > install this software on local servers in this offices.
> >
> > In this offices will be performed some major tasks like: add a contract,
> > planifications, report writings etc. We already use Slony for a
> > datatransfer to a client, but he can only read the data's and it is ok
> > so. But in this offices will be a lot of writing in the database. That is
> > why I wanted a multi master replications. Most of the tables are "static"
> > tables. I mean that they contain lists... that somehow are "fix"... can
> > be user as "read_only" in these offices. But a task like: add a contract
> > writes data in at least 8 tables, planning in 3, report writing in 6 or 7
> > didn't count them exactly.

What it sounds like is that you want asynchronous multi-master replication by 
partition ... the SyBase model.   Bascially, you need to set things up so 
that each office is the "master" of its own data and a "slave" for other 
offices' data.

You could do this using table partitioning (inheritance) and Slony-I.   
Frankly, though, I'd find a custom code solution to be less kludgy than that: 
a set of PL/perl,python, or Java triggers which would track which rows the 
local office was master of and prevent updates to other rows.

Regardless, this isn't just something you can retrofit onto an existing 
application and expect it to work smoothly.   You'll need to do a lot of 
back-end redesign around this requirement.  That's equally true in Sybase or 
MSSQL or Oracle, it's not just Postgres.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco