Re: Speed up the removal of WAL files - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Speed up the removal of WAL files
Date
Msg-id 20180307021315.GD1744@paquier.xyz
Whole thread Raw
In response to Re: Speed up the removal of WAL files  (Fujii Masao <masao.fujii@gmail.com>)
Responses RE: Speed up the removal of WAL files  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: check error messages in SSL tests
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed