| From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | 'Michael Paquier' <michael(at)paquier(dot)xyz> |
| Cc: | 'Fujii Masao' <masao(dot)fujii(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: Speed up the removal of WAL files |
| Date: | 2018-02-21 08:27:40 |
| Message-ID: | 0A3221C70F24FB45833433255569204D1F8D0DB4@G01JPEXMBYT05 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Michael Paquier [mailto:michael(at)paquier(dot)xyz]
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
Hmm, you're right. Even during recovery, RemoveOldXlogFiles() can't skip fsyncing pg_wal/ because new WAL records streamed from the master are written to recycled WAL files.
After all, it seems to me that we have to stand with the current patch which only handles RemoveNonParentXlogFiles().
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro HORIGUCHI | 2018-02-21 08:32:31 | Re: [HACKERS] asynchronous execution |
| Previous Message | Michael Paquier | 2018-02-21 07:52:50 | Re: Speed up the removal of WAL files |