Re: Speed up the removal of WAL files
От | Fujii Masao |
---|---|
Тема | Re: Speed up the removal of WAL files |
Дата | |
Msg-id | CAHGQGwHXd+39svrz8KZZwKOY6VdwQqXQbMVaGh2r3cKRwvzgFg@mail.gmail.com обсуждение исходный текст |
Ответ на | 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 Fri, Nov 17, 2017 at 5:20 PM, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote: > From: Kyotaro HORIGUCHI [mailto:horiguchi.kyotaro@lab.ntt.co.jp] >> The orinal code recycles some of the to-be-removed files, but the patch >> removes all the victims. This may impact on performance. > > Yes, I noticed it after submitting the patch and was wondering what to do. Thinking simply, I think it would be just enoughto replace durable_unlink/durable_rename in RemoveXLogFile() with unlink/rename, and sync the pg_wal directory oncein RemoveNonParentXlogFiles() and RemoveOldXlogFiles(). This will benefit the failover time when fast promotion is notperformed. What do you think? It seems not good idea to just replace durable_rename() with rename() in RemoveOldXlogFiles()->RemoveXlogFiles()->InstallXLogFileSegment(). Because that change seems to be able to cause the following problem. 1. Checkpoint calls RemoveOldXlogFiles(). 2. It recycles the WAL file AAA to BBB. pg_wal directory has not fsync'd yet. 3. Another transaction (TX1) writes its WAL data into the (recycled) file BBB. 4. CRASH and RESTART 5. The WAL file BBB disappears and you can see AAA, but AAA is not used in recovery. This causes data loss of transaction by Tx1. Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: