Victor Sudakov <vas@xxxxxxxxxx> writes: > When a cluster is in recovery mode (a delayed replica, PITR etc), does > the setting of "fsync = off" speed up the application of WALs? > I've done some experimenting and got dubious results, so what does the > theory say? I think it should make things faster, but maybe not by enough to notice. In normal operation, the main place that fsync is a bottleneck is the need to fsync new WAL down to disk before reporting a transaction as committed. That doesn't apply in recovery of course: we're reading WAL not writing it. The next source of fsync stalls is that we don't consider a checkpoint complete until all the required writes are fsync'd. But that is nearly independent of WAL application, since checkpointing is done by a separate background process. I think it'd just manifest as additional pressure on the I/O hardware, possibly slowing down reads or writes that the replay process has to do. I believe there are certain specific operations (database creation comes to mind) where we need to fsync as part of the operation because we don't rely on the WAL apparatus to backstop all of the I/O. So the requirement for fsync would fall on the replay process when replaying one of these. But your workload might not involve much of any of those operations. regards, tom lane
