> I suspect we haven't got a common understanding of what "inconsistent"
> means, which is liable to make it difficult to discuss that further.
 
sorry for using bad db terminology, but what I meant was that for my
setup, in case the master/slave goes down during replication, the
application doing batch runs on top would not be able to recover. On
the other hand, running the replication daemons later would make sense
for me as I have loads of memory (32GB) , and would like to always see
the slave in exactly 1 of 2 situations after a reboot/recover : all
transactions of the batches incorporated, or none of them.
I agree that better hardware does not condone bad design, but if there
is any other way of maintaining the slave in an app-readable state, I
would invite any suggestions.
Note that probably the best way is to redesign the app, but my focus
right now is on convincing my employers that postgres-slony would work
and should throw oracle out.

Also I would still like to know how to configure slony to resync
master and slave as fast as possible. Do I specify some special
command line options to the slon daemon? or some other configuration
options exist?

thanks a lot !
paraM