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 :-(.
-- 
output = reverse("ofni.sailifa.ac" "@" "enworbbc")
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)