On Oct 24, 2013, at 18:10, maillists0@xxxxxxxxx wrote: > Thank you for the answers. I'm still confused. If fsync is not replicated to the slave, then how is replication affected by a corrupt master? If the master dies and there's a commit recorded in the wal log that didn't actually happen, wouldn't the slave still be expected to be in a sane state, with the wal logs accurately reflecting what's on disk? > > Maybe I just don't understand streaming replication enough. The docs seem to say that synchronous commits mean that the slave also has to verify a write before a transaction is considered complete. How does fsync affect the way/order in which statements are sent to the slave for replication? What you're missing is that the master will be replicating corrupt data. That is, _if_ it gets corrupted of course. But, data corruption in a database has a tendency to go unnoticed for a while. A corrupted master doesn't necessarily break down immediately - in fact, it can remain running for quite a while as long as the corruption doesn't break stuff in the wrong places or as long as the corrupted records don't get fetched. Until that time, corruption is just blocks of data on disk, which quite possibly end up being replicated to the slave. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
