Re: Speed up the removal of WAL files

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Speed up the removal of WAL files
Дата
Msg-id 20180221075250.GB1632@paquier.xyz
обсуждение исходный текст
Ответ на RE: Speed up the removal of WAL files  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Ответы RE: Speed up the removal of WAL files
Re: Speed up the removal of WAL files
Список pgsql-hackers
On Wed, Feb 21, 2018 at 07:20:00AM +0000, Tsunakawa, Takayuki wrote:
> Right.  Then I thought of doing the following to avoid making a new
> function only for RemoveNonParentXlogFiles() which is similar to
> RemoveXlogFile().
>
> * Add an argument "bool durable" to RemoveXlogFile().  Based on its
> value, RemoveXlogFile() calls either durable_xx() or xx().
>
> * Likewise, add an argument "bool durable" to InstallXLogFileSegment()
> and do the same.
>
> * RemoveNonParentXlogFiles() calls RemoveXlogFile() with
> durable=false.  At the end of the function, sync the pg_wal directory
> with fsync_fname().
>
> * RemoveOldXlogFiles() does the same thing.  One difference is that it
> passes false to RemoveXlogFile() during recovery (InRecovery == true)
> and true otherwise.

It seems to me that you would reintroduce partially the problems that
1d4a0ab1 has fixed.  In short, if a crash happens in the code paths
calling RemoveXlogFile with durable = false before fsync'ing pg_wal,
then a rename has no guarantee to be durable, so you could finish again
with a file that as an old name, but new contents.  A crucial thing
which matters for a rename to be durable is that the old file is sync'ed
as well.
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
Следующее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: RE: Speed up the removal of WAL files