| Thomas F. O'Connell 2005-08-05, 11:24 am |
| I read this thread with some interest because Slony seems, at first =20
glance, to be a nice safety lock for the foot-gun of running =20
PostgreSQL with fsync off.
The general concern for running with fsync off in a standalone =20
PostgreSQL environment is the worst-case scenario of winding up in an =20=
unrecoverable state.
Since Slony is a trigger-based replication system, though, I'm having =20=
a hard time seeing how "unrecoverable data corruption" resulting from =20=
fsync off on a Slony origin could result in the same situation =20
occurring on a subscriber.
As long as one considers the origin completely lost, isn't the worst =20
case for a subscriber the possibility of missing transactions or =20
receiving incomplete transactions?
In a real-world failover scenario where an application expects 100% =20
uptime from an underlying database, there will always be a small =20
interval where the database is unreachable, so if this is acceptable, =20=
it seems like a worst case of replicating incomplete transactions =20
might also be acceptable.
My concern would be a subscriber that were left in a state in which a =20=
pg_dump could no longer be taken or some other form of "unrecoverable =20=
data corruption". Can someone post an example of what form that might =20=
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 =20=
seem like inconsistencies that could be corrected.
Original thread: http://gborg.postgresql.org/piperma...y1-general/=20=
2005-March/001757.html
Thanks!
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
Strategic Open Source: Open Your i=99
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005
|