Re: Speed up the removal of WAL files

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Speed up the removal of WAL files
Дата
Msg-id 20180307021315.GD1744@paquier.xyz
обсуждение исходный текст
Ответ на Re: Speed up the removal of WAL files  (Fujii Masao <masao.fujii@gmail.com>)
Ответы RE: Speed up the removal of WAL files  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Список pgsql-hackers
On Wed, Mar 07, 2018 at 12:55:43AM +0900, Fujii Masao wrote:
> So, what about, as another approach, making the checkpointer instead of
> the startup process call RemoveNonParentXlogFiles() when end-of-recovery
> checkpoint is executed? ISTM that a recovery doesn't need to wait for
> RemoveNonParentXlogFiles() to end. Instead, RemoveNonParentXlogFiles()
> seems to have to complete before the checkpointer calls RemoveOldXlogFiles()
> and creates .ready files for the "garbage" WAL files on the old timeline.
> So it seems natual to leave that WAL recycle task to the checkpointer.

Couldn't that impact the I/O performance at the end of recovery until
the first post-recovery checkpoint is completed?  Let's not forget that
since 9.3 the end-of-recovery checkpoint is not triggered immediately,
so there could be a delay.  If WAL segments of the past timeline are
recycled without waiting for this first checkpoint to happen then there
is no need to create new, zero-emptied, segments post-recovery, which
can count as well.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: check error messages in SSL tests
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] make async slave to wait for lsn to be replayed