According to manual, when you set "synchronous_commit" to on, the transaction commits will wait until master and slave flush the commit record of transaction to the physical storage, so I think even if turn off the fsync on master is safe for data consistency and data will not be lost if slave physical storage is not damaged.
If "synchronous_commit" is set to remote_write, the transaction commits will wait until slave to write the data to os. Data will lose if master crashed and slave os crashed. But acording to WAL documents it will not crash the data consistency on slave if slave fsync not off.
Otherwise fsync off on master may will result in losing data when master crashes, but still keep consistency on the slave if the slave is not crashed or slave's fsync is on .
See follow:
http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-FSYNC fsync and synchronous_commit
http://www.postgresql.org/docs/current/static/wal-intro.html
------------------ Original ------------------
From: "maillists0";<maillists0@xxxxxxxxx>;
Date: Thu, Oct 24, 2013 09:39 AM
To: "pgsql-general"<pgsql-general@xxxxxxxxxxxxxx>;
Subject: [GENERAL] Replication and fsync
Newb question.
I'm running 9.1 with a slave using streaming replication. A coworker wants to turn off fsync on the master and insists that the slave will still be in a usable state if there is a failure on the master. We all know that turning off fsync is a bad idea, but I was under the impression that the fsync setting would be replicated to the slave, making it useless as a backup in this scenario. Am I wrong? If I'm wrong, is there still danger to the slave in this kind of setup? Can I count on it remaining unharmed if the master suffers unrecoverable corruption?