From: Tom Lane <tgl@sss.pgh.pa.us>
To: Victor Sudakov <vas@sibptus.ru>
Cc: pgsql-admin@lists.postgresql.org
Subject: Re: "fsync = off" in recovery
Date: Wed, 07 Apr 2021 11:35:01 -0400
Message-ID: <1593539.1617809701@sss.pgh.pa.us> (raw)
In-Reply-To: <YG3OEx8aSe2JU175@admin.sibptus.ru>
References: <YG3OEx8aSe2JU175@admin.sibptus.ru>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: tgl@sss.pgh.pa.us, vas@sibptus.ru, pgsql-admin@lists.postgresql.org
Subject: Re: "fsync = off" in recovery
In-Reply-To: <1593539.1617809701@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox