> Hi Andrew
>
> I thank you for the reply, your suggestions are quite good, but it is
> still not possible for me to convince my CHEF to adapt SLONY-I in the
> prod. env. because of the non sync.-ed data in case of a failover .
>
> My question is :
>
> IS IT POSSIBLE TO CONFIGURE SLONY-I SO THAT :
> - DML changes will be commited on the Master only after they are
> SYNC.-ed to the slave.

No, events never go on to subscribers until after they are successfully
applied on the origin node.

There was a brief discussion at the Anniversary Summit about the notion of
maybe using PREPARE TRANSACTION and handling this sort of thing via 2
phase commit, but there seemed to be general agreement that it's not the
right time for that.

> - I mean it is better for me (if my data-records will not be written on
> the master), than (written on master and missed on the slave after a
> failover as example).

I fully understand the issue; you don't want to have the possibility of
some transactions being missed on FAILOVER that were reported to customers
as completed.

Unfortunately, no, there's not a way to make Slony-I wait in this fashion.

> - Knowing that : - I work with a SLON Sync-Interval of  500 msec and
> will reduce it now to 100 msec

Dropping the SYNC interval that way may not be as useful as you think; it
*may* reduce the latency time, but it may also add more replication work,
adding something back to the latency time.

The intervals are not "real time guarantees," so you can't depend on them
as perfect protection from problems that may arise.

And remember, if your origin node starts failing, say with disk drives
falling over, that will likely degrade system behaviour before it actually
leads to outright failure.