Re: "fsync = off" in recovery - Mailing list pgsql-admin

From Tom Lane
Subject Re: "fsync = off" in recovery
Date
Msg-id 1593539.1617809701@sss.pgh.pa.us
Whole thread Raw
In response to "fsync = off" in recovery  (Victor Sudakov <vas@sibptus.ru>)
List pgsql-admin
Victor Sudakov <vas@sibptus.ru> 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



pgsql-admin by date:

Previous
From: Victor Sudakov
Date:
Subject: "fsync = off" in recovery
Next
From: lejeczek
Date:
Subject: Replication & TLS encryption - how?