pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feed"fsync = off" in recovery
2+ messages / 2 participants
[nested] [flat]
* "fsync = off" in recovery
@ 2021-04-07 15:21 Victor Sudakov <vas@sibptus.ru>
0 siblings, 1 reply; 2+ messages in thread
From: Victor Sudakov @ 2021-04-07 15:21 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
Dear Colleagues,
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?
--
Victor Sudakov VAS4-RIPE
http://vas.tomsk.ru/
2:5005/49@fidonet
Attachments:
signature.asc (application/pgp-signature, 454B) download
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: "fsync = off" in recovery
@ 2021-04-07 15:35 Tom Lane <tgl@sss.pgh.pa.us>
parent: Victor Sudakov <vas@sibptus.ru>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2021-04-07 15:35 UTC (permalink / raw)
To: Victor Sudakov <vas@sibptus.ru>; +Cc: pgsql-admin@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2021-04-07 15:35 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-04-07 15:21 "fsync = off" in recovery Victor Sudakov <vas@sibptus.ru>
2021-04-07 15:35 ` Tom Lane <tgl@sss.pgh.pa.us>
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