Re: Use durable_unlink for .ready and .done files for WAL segment removal

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: bossartn(at)amazon(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Use durable_unlink for .ready and .done files for WAL segment removal
Date: 2018-12-06 05:43:35
Message-ID: 20181206054335.GH2407@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergei Agalakov 2018-12-06 06:01:27 Re: Limitting full join to one match
Previous Message Amit Kapila 2018-12-06 05:42:53 Re: zheap: a new storage format for PostgreSQL