At Thu, 7 Apr 2022 11:29:54 -0700, Nathan Bossart <nathandbossart@gmail.com> wrote in
> The attached patch prevents this problem by using durable_rename() instead
> of durable_rename_excl() for WAL recycling. This removes the protection
> against accidentally overwriting an existing WAL file, but there shouldn't
> be one.
From another direction, if the new segment was the currently active
one, we just mustn't install it. Otherwise we don't care.
So, the only thing we need to care is segment switch. Without it, the
segment that InstallXLogFileSegment found by the stat loop is known to
be safe to overwrite even if exists.
When segment switch finds an existing file, it's no problem since the
segment switch doesn't create a new segment. Otherwise segment switch
always calls InstallXLogFileSegment. The section from searching for
an empty segmetn slot until calling durable_rename_excl() is protected
by ControlFileLock. Thus if a process is in the section, no other
process can switch to a newly-created segment.
If this diagnosis is correct, the comment is proved to be paranoid.
> * Perform the rename using link if available, paranoidly trying to avoid
> * overwriting an existing file (there shouldn't be one).
As the result, I think Nathan's fix is correct that we can safely use
durable_rename() instead.
And I propose to use renameat2 on Linux so that we can detect the
contradicting case by the regression tests even though only on Linux.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center