RE: Speed up the removal of WAL files - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Speed up the removal of WAL files
Date
Msg-id 0A3221C70F24FB45833433255569204D1F81B241@G01JPEXMBYT05
Whole thread Raw
In response to Re: Speed up the removal of WAL files  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Speed up the removal of WAL files  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
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?
 

BTW, RemoveNonParentXlogFiles() recycles only 10 WAL files and delete all other files.  So the impact of modification
islimited.
 


> 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
performsthe deletion again during the next recovery.
 

Regards
Takayuki Tsunakawa






pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Speed up the removal of WAL files
Next
From: Marco Nenciarini
Date:
Subject: Re: pspg - psql pager