From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@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 enough to replace durable_unlink/durable_rename in RemoveXLogFile() with unlink/rename, and sync the pg_wal directory once in RemoveNonParentXlogFiles() and RemoveOldXlogFiles(). This will benefit the failover time when fast promotion is not performed. What do you think? BTW, RemoveNonParentXlogFiles() recycles only 10 WAL files and delete all other files. So the impact of modification is limited. > Likewise the original code is using durable_unlink to actually remove a > file so separating unlink and fsync might resurrect the problem that should > have been fixed by > 1b02be21f271db6bd3cd43abb23fa596fcb6bac3 (I'm not sure what it was but you > are one of the reviwers of it). I suppose that you need to explain the reason > why this change doesn't risk anything. It's safe because the directory is finally synced. If the database server crashes before it deletes all WAL files, it performs the deletion again during the next recovery. Regards Takayuki Tsunakawa
