Re: Speed up the removal of WAL files

On Wed, Mar 07, 2018 at 06:15:24AM +0000, Tsunakawa, Takayuki wrote:
> Good point. I understood you referred to PreallocXlogFiles(), which
> may create one new WAL file if RemoveNonParentXlogFiles() is not
> called or does not recycle WAL files in the old timeline.
>
> The best hack (or a compromise/kludge?) seems to be:
>
> 1. Modify durable_xx() functions so that they don't fsync directory
> hanges when enableFsync is false.
>
> 2. RemoveNonParentXlogFiles() sets enableFsync to false before the
> while loop, restores the original value of it after the while loop,
> and fsync pg_wal/ just once. What do you think?

Hm. durable_xx should remain a sane operation as an isolated call as
you still get the same problem if a crash happens before flushing the
parent... Fujii-san idea also has value to speed up the end of recovery
but this costs as well in extra recycling operations post promotion. If
the checkpoint was to happen a the end of recovery then that would be
more logic, but we don't for performance reasons. Let's continue to
discuss on this thread. If you have any patch to offer, let's also look
at them.

Anyway, as things are pretty much idle on this thread for a couple of
days and that we are still discussing potential ideas, I think that this
entry should be marked as returned with feedback. Thoughts?
--
Michael