On Wed, Mar 22, 2017 at 12:46 AM, Teodor Sigaev <teodor@sigaev.ru> wrote:
>>>> If that can happen, don't we have the same problem in many other places?
>>>> Like, all the SLRUs? They don't fsync the directory either.
>>>
>>> Right, pg_commit_ts and pg_clog enter in this category.
>>
>>
>> Implemented as attached.
>>
>>>> Is unlink() guaranteed to be durable, without fsyncing the directory? If
>>>> not, then we need to fsync() the directory even if there are no files in
>>>> it
>>>> at the moment, because some might've been removed earlier in the
>>>> checkpoint
>>>> cycle.
>
> What is protection if pg crashes after unlimk() but before fsync()? Right,
> it's rather small window for such scenario, but isn't better to have
> another protection?
This may apply in some cases, but my lookup on the matter regarding
this patch is that we don't actually need something like that yet,
because there are no cases where we could apply it:
- Removal of past WAL segments is on a per-node base.
- Installation of new segments is guessable.
- Removal of backup_label and tablespace map is based on the timings
of pg_start/stop_backup, once again on a per-node basis.
This patch reduces the window to the minimum we can do: once
durable_unlink() leaves, we can guarantee that the system is in a
durable state.
> Like WAL-logging of WAL segment removing...
The pace of removal of the WAL segments is different on each node, and
should be different on each node (for example there could be
replication slots with different retention policies on cascading
downstream standbys). So that's not a concept you can apply here.
--
Michael
