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
|
Список | 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 по дате отправления: