On Wed, 2007-05-09 at 08:26 -0600, Scott Ribe wrote: > > I still wouldn't trust Slony with fsync off. Another scenario would be > > the Slony trigger writes a change to the Slony DB, the db crashes before > > it gets committed to disk. When the DB is started, no errors prevent > > startup, but that transaction is lost. > > I'm not sure, but I think the questioner was proposing a policy of "if it > crashes, we go to the standby, no attempt at recovery, ever", and I think > that would be safe. Just make sure that there is no way that the database would come back up after the crash. If it did, the slons could pick up and cause you trouble. If you disable all start up scripts, and operate under the assumption that crash=corruption=failover to Slony replica, you should be okay. You will lose whatever transactions were not replicated to the subscriber, but that's inherent to async replication. > And, personally, given my experience with pg, I think that's reasonable. > Because the day I see pg crash I'm going to assume I have a hardware problem > ;-) If you care about your data, leave fsync on. Period. If you can accept the potential for data loss, and you've proven that there is a worthwhile performance benefit from turning it off (which there may not be), and you gotten your boss/clients/stakeholders to sign off (preferably in writing) that data loss is acceptable if the db crashes, then go ahead and turn it off. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp.
