To that point, think about the complexities in dealing with merge conflicts.
Client A (offline) makes a change to record 12345
Client B (offline) makes a change to record 12345

Merge takes place.
Who's change becomes effective?
Last man in the pool?  How do you let Client A know that his changes 
never became effective.?

Jeff Amiel





Christopher Browne wrote:

>david at codepoets.co.uk writes:
>  
>
>>I've not had a chance to look in detail at the slony replication software,
>>however I was hoping someone could answer the following :
>>
>>
>>One master postgresql database, which client postgresql's sync with. This
>>essentially gives you one central repository, and allowing clients to work
>>offline if needs be.
>>
>>
>>The client postgresql's may not be online all the time, so some sort of manual
>>sync would need to be initiated.
>>
>>
>>Some questions :
>>
>>1) Is it possible to sync on demand (therefore allowing the clients to be
>>disconnected from the network for extended periods of time?)
>>    
>>
>
>Yes, that certainly works.
>
>I had the interesting situation yesterday of setting up two Rather
>Large subscribers.  I discovered the "idiosyncracy" that Slony-I can't
>cope with populating two subscribers from the same node at the same
>time.  (I can think of a possible workaround if you have multiple
>nodes populated, but I'm in "bootstrapping" mode, at present...)
>
>One of the "children" took several hours to load; the second one
>couldn't even _start_ until after that.
>
>And the "master" node was still undergoing updates throughout the
>whole time.  It had to collect up those updates, and store them until
>such time as both subscribers were ready to accept them.
>
>  
>
>>2) Can the clients/slaves be updated? Or is it strictly read only access from
>>the slave?
>>    
>>
>
>Strictly read-only access.
>
>Looking at a table on a subscribing node:
>
>appschema=# \d app_object_status
>                                Table "public.app_object_status"
>  Column   |         Type          |                          Modifiers                          
>-----------+-----------------------+-------------------------------------------------------------
> object_id | integer               | not null
> status    | integer               | not null
> reason    | character varying(64) | 
> _rserv_ts | integer               | not null default nextval('_rserv_app_doma_stat_seq_'::text)
>Indexes:
>    "app_object_status_pkey" primary key, btree (object_id, status)
>    "_rserv_app_obj_stat_idx" unique, btree (_rserv_ts)
>Triggers:
>    _appschema_denyaccess_6 BEFORE INSERT OR DELETE OR UPDATE ON app_object_status FOR EACH ROW EXECUTE PROCEDURE _appschema.denyaccess('_appschema')
>
>appschema=# 
>
>That trigger rejects updates to the table.
>
>  
>
>>3) Is it two way replication?
>>    
>>
>
>Based on the answer to #2, obviously not.
>
>  
>
>>4) Would it be possible to sync a portion of the database (e.g. all records
>>belonging to a client) ?
>>    
>>
>
>Slony-I syncs tables.  If you modelled your database so as to separate
>some clients out to separate tables, then yes, you could sync just a
>portion.
>
>  
>
>>5) Is there a limit to the number of clients? (Probably talking in the region of
>>500-1000 clients)
>>    
>>
>
>This has the feel of "going further than intended."  I hesitate to
>call it "impossible," but I wouldn't want to be responsible for
>keeping any promises about a project to do so...
>
>  
>
>>I'm looking for a solution which would allow users to work offline,
>>and update when dialed up online. Hence the idea of running postgres
>>locally, and syncing with a remote central server when it's
>>availble.
>>    
>>
>
>What you're describing sounds a whole lot like the model in Lotus
>Notes.  That's a fair bit different from the intent of Slony-I.  I
>don't think it really fits.  There are plans for there to be a
>"Slony-II" that would offer some form of "multimaster" support; in
>that it starts with Slony-I as the basis for the "initial sync," I
>wouldn't expect it to help for your situation, alas.
>
>Jan mentioned in his preliminary papers when planning Slony-I that
>there are a number of quite different models to replication, and the
>scenario you're describing looks like an excellent example of this.
>
>What you realistically need is a server-side application that has an
>operating model more akin to the way a PalmPilot does "syncs" between
>the unit you carry in your pocket and the desktop.  
>
>Doing that in some "generic" way with a set of databases (e.g. - where
>there's a replication framework intended to be reused for different
>applications) would be an excellent project that, regrettably, happens
>to be extremely different from Slony-I.  
>
>The issues are different; the challenges would be different; I think
>it would be a fascinating project.  But it's not Slony :-(.
>  
>