I read this thread with some interest because Slony seems, at first  
glance, to be a nice safety lock for the foot-gun of running  
PostgreSQL with fsync off.

The general concern for running with fsync off in a standalone  
PostgreSQL environment is the worst-case scenario of winding up in an  
unrecoverable state.

Since Slony is a trigger-based replication system, though, I'm having  
a hard time seeing how "unrecoverable data corruption" resulting from  
fsync off on a Slony origin could result in the same situation  
occurring on a subscriber.

As long as one considers the origin completely lost, isn't the worst  
case for a subscriber the possibility of missing transactions or  
receiving incomplete transactions?

In a real-world failover scenario where an application expects 100%  
uptime from an underlying database, there will always be a small  
interval where the database is unreachable, so if this is acceptable,  
it seems like a worst case of replicating incomplete transactions  
might also be acceptable.

My concern would be a subscriber that were left in a state in which a  
pg_dump could no longer be taken or some other form of "unrecoverable  
data corruption". Can someone post an example of what form that might  
take for a subscriber if fsync is disabled on the origin?

Chris Browne mentioned:

  a) See entries that had never been committed

  b) Miss entries that were not properly committed

But these don't seem like "unrecoverable data corruption" to me. They  
seem like inconsistencies that could be corrected.

Original thread: http://gborg.postgresql.org/pipermail/slony1-general/ 
2005-March/001757.html

Thanks!

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i?

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005