Re: "fsync = off" in recovery

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "fsync = off" in recovery
Дата
Msg-id 1593539.1617809701@sss.pgh.pa.us
обсуждение исходный текст
Ответ на "fsync = off" in recovery  (Victor Sudakov <vas@sibptus.ru>)
Список 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 по дате отправления:

Предыдущее
От: Victor Sudakov
Дата:
Сообщение: "fsync = off" in recovery
Следующее
От: lejeczek
Дата:
Сообщение: Replication & TLS encryption - how?