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
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
