From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Speed up the removal of WAL files |
Date: | 2018-03-07 02:13:15 |
Message-ID: | 20180307021315.GD1744@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-03-07 02:25:21 | Re: [HACKERS] make async slave to wait for lsn to be replayed |
Previous Message | Michael Paquier | 2018-03-07 01:46:24 | Re: BUG #14999: pg_rewind corrupts control file global/pg_control |