Tomas Vondra wrote: > On 22 Listopad 2011, 18:16, Bruce Momjian wrote: > > Tomas Vondra wrote: > >> While I don't recommend it, fsync=off definitely is an option, > >> especially > >> with sync replication. The synchronous_commit is not a 1:1 replacement. > >> > >> Imagine for example a master with lot of I/O, and a sync standby. By > >> setting fsync=off on the master and fsync=on on the slave the master > >> does > >> not need to wait for the fsync (so the I/O is not that stressed and can > >> handle more requests from clients), but the slave actually does fsync. > >> > >> So you don't force local fsync, but you're waiting for fsync from the > >> standby. But standby doesn't need to handle all the I/O the primary has. > >> > >> You can't do this with synchronous_commit - that basically forces you to > >> do local fsync on commit, or not to wait for the commit at all. > >> > >> Tomas > >> > >> Disclaimer: I haven't actually tried this, so maybe I missed something. > > > > I think you did. synchronous_commit really means fsync so that the > > system is alway consistent --- there is no waiting for the fsync to > > happen on the master (unless I am totally missing something). With > > fsync off, you can get into cases where the heap/index files are pushed > > to disk before the wal gets written to disk, causing the system to be > > inconsistent in case of a crash replay. > > Well, but this inconsistency can happen only on the master, right? The > slave receives on the WAL records in order, and applies them just fine. > And it's fsync=on so it is not vulnerable to this kind of data corruption. True. > When the master crashes, the recovery may fail - that's expected. The > master would have to be rebuilt from scratch in this scenario. Ah, the recovery perhaps doesn't generate an error. It might come up just fine, but be inconsistent. > Yes, I know that synchronous_commit actually guarantees data consistency. > The point of the suggested scenario was that > > (a) the master does not wait for the I/O (assuming that it's busy and the > latency would be significant) > > (b) the master waits for the slave (sync replication) > > so that you know that in case of crash of the master the slave actually > contains all the data. That's not what synchronous_commit does - you may > loose data if you use it. Yes, that would work. > > I think the only use of fsync off is for performance testing so see how > > expensive fynsc is. > > There's at least one more quite commonly used scenario - restoring a > database from backup. It often speeds the process significantly and when > something fails, you can simply start again. True. -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
