Hello,

I run a Slony cluster (2.0.2, PG 8.4 on master, 8.3 on 5 slaves) where
an application that runs on each slave should commit transactions
quickly - it's supposed to be a realtime system. I have decided that
the trade-off between performance and data integrity offered by
turning off synchronous_commit in postgresql.conf on each slave (but
not the master) is acceptable - the window for data loss is very
small, as all the activity is small transactions. Obviously, they
aren't touching replicated tables, but their own tables that aren't in
any replication set. We don't perform cascading or failover - it's a
rather simple set-up, as Slony clusters go.

My concern with turning off synchronous_commit is the potential that
it might break replication, if a slave and the master were left in an
inconsistent state. Breaking replication is far more expensive to me
than losing one of my small transactions.

I am aware that it's possible to specify whether or not
synchronous_commit is used on a transaction by transaction basis, but
it isn't apparent how I can do this with the Qt database driver that I
use, that wraps libpq. I'm using implicit transactions by calling
pl/pgSQL functions on the slaves (every modifying operation is a
function call). Perhaps that should be the next thing I investigate if
turning synchronous_commit off server wide in postgresql.conf on
slaves turns out to be a bad idea.

What sort of risk am I assuming specifically to replication by turning
off synchronous_commit on the slaves but not on the master?

Thanks,
Peter Geoghegan