Hi James,
  I'm definitely not the Slony expert of this list, but I'm pretty
confused by your description.  Could you try simplifying it and making
it more generic?  It's hard to parse, but I tried.  See below.

James T Mugauri wrote:
> We are trying to implement centralised customer billing and
> relationship management while enabling each geographic area to have
> independence in terms of Authorization and Authentication of customer
> devices... These latter functions are carried out by a
> Motorola-developed application running on a Postgres database.

To clarify, "these latter functions" refer to auth?  So you want
separate geographic locations to have their own auth data.  Each
location has a Motorola application that uses this auth data.  Is that
right?

> This interfaces with the CRM and billing application on one hand for 
> authentication et al, and Wi-Max base stations for Accounting on the 
> other hand.. 

So is "This" the Postgresql database?  It sounds like each geographic
location has several applications that connect to a database.  The CRM
app and the Billing app use Postgresql for auth data (usernames,
passwords, etc).  The Wi-Max base stations (aka Motorola app?) use
Postgresql to store accounting data.  Is this right?

> Obviously, with 3 (and soon more) areas in operation, these have to
> all syncronise the accounting data with the head office database (one
> of the 3) while sourcing Authentication and Authorisation details from
> the same head office 'mothership'.

Warning bells sound when I see 'synchronize'.  It sounds like each of
your geographic locations must write auth data and accounting data to
the location's local postgresql database.  And you want some mechanism
to synchronize each location's local database with every other location?

> This suggests to me that while i can have all 3 in the same
> replication set for the purposes of authentication/authorisation, I
> have to set up separate replication sets for accounting data as
> follows:
> 
> 1. Each satellite is the master node of a replication set with the
> head office where, crucially
> 2. The head office also allows local updates to itself

I don't think I can answer these until I get clarification on my
questions above.  But it's important that you remember what kind of
replication Slony provides:  asynchronous master->slave replication.
Writes to any replicated table can happen only on the "master" aka
"origin" aka "provider" node.

Dane
---
Dane Miller
Systems Administrator
Greatschools.net
http://www.greatschools.net