Re: Use durable_unlink for .ready and .done files for WAL segmentremoval
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: Use durable_unlink for .ready and .done files for WAL segmentremoval |
| Дата | |
| Msg-id | 20181206054335.GH2407@paquier.xyz обсуждение |
| Ответ на | Re: Use durable_unlink for .ready and .done files for WAL segmentremoval (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
| Ответы |
Re: Use durable_unlink for .ready and .done files for WAL segmentremoval
|
| Список | pgsql-hackers |
On Thu, Dec 06, 2018 at 01:55:46PM +0900, Kyotaro HORIGUCHI wrote: > durable_unlink has two modes of faiure. Failure to unlink and > fsync. If once it fails at the fsync stage, subsequent > durable_unlink calls for the same file always fail to unlink with > ENOENT. If durable_unlink is intended to be called repeatedly on > falure, perhaps it should return a different code for each > failure so that the caller can indentify what to do next. Why? A WARNING would be logged if the first unlink() fails, and another, different WARNING would be logged if the subsequent fsync fails. It looks enough to me to make a distinction between both. Now, you may have a point in the fact that we could also live with only using unlink() for this code path, as even on repetitive crashes this would take care of removing orphan archive status files consistently. -- Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера