Hi again. I've read all the possible solutions you've proposed. Of course I
have to thank you all for this. Thank you very much for your time.

As Christopher Browne, Hannu Krosing, Jens Schicke and Dirk Jagdmann said,
Slony can't solve this problem on its own. However I will use Slony anyway,
for backup purposes, and to take advantage of the fail-over Slony provides.
To solve the synchronization problem, what Dirk proposed, was what I had in
mind beforehand, so that's the primary solution I will try for that issue.
Thanks Dirk!

While I implement and test this solution, one of my partners will try with a
VPN between Headquarters and the other offices. So all users (remote or
local from master server point of view) will read and write to master,
hoping that VPN will improve greatly the response time for my application. I
think that will work for now...The slaves will be available as read-only
access for the users in remote offices, should the master fall down.

Many Thanks to all of you for taking the time to answer me. I hope this
doubt helps someone else, and I hope to help you back sometime.

I will write again here if I make any advance with all this. thanks again.

Marco.

On 4/1/06, Dirk Jagdmann <jagdmann at gmail.com > wrote:
>
> Hello Marco,
>
> > So I ask: Are there any solutions that may help me reduce/avoid this
> delay
> > or at least prevent the slave server to respond to the user until the
> > replication have propagated to all the slaves (or at least the one which
> > originates the writes)? Maybe some kind of combination between
> asynchronous
> > replication (provided by Slony-I) and synchronous replication?
>
> I think you should not try to solve this issue in the database, but
> rather your application. I would suggest you setup your application,
> so that read requests to the database are initially done on the slave
> servers (for remote sites) and once you have to do any write queries
> you switch your database connection to the master site and from that
> point on use the master db for the rest of the application session. Of
> course you could be a bit more fancier, so that you add a timeout
> value (for example 1min, but you should see how fast your replication
> works) and if there have not been any write queries in the last
> "timeout" minutes (or seconds or whatever) you can switch your
> database connection back to a slave.
>
> --
> ---> Dirk Jagdmann
> ----> http://cubic.org/~doj <http://cubic.org/%7Edoj>
> -----> http://llg.cubic.org
>



--
********************************
Marco A. Canderle
marcocanderle at gmail.com
********************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20060404/eaec3c7c/attachment-0001.html