On Fri, Apr 08, 2022 at 09:00:36PM -0400, Robert Haas wrote:
> > I think there might be another problem. The man page for rename() seems to
> > indicate that overwriting an existing file also introduces a window where
> > the old and new path are hard links to the same file. This isn't a problem
> > for the WAL files because we should never be overwriting an existing one,
> > but I wonder if it's a problem for other code paths. My guess is that many
> > code paths that overwrite an existing file are first writing changes to a
> > temporary file before atomically replacing the original. Those paths are
> > likely okay, too, as you can usually just discard any existing temporary
> > files.
>
> I wonder if this is really true. I thought rename() was supposed to be atomic.
Looks like it's atomic in that it's not like cp + rm, but not atomic the other
way you want.
| If newpath already exists, it will be atomically replaced, so that there is no point at which another
processattempting to access newpath will find it missing. However, there will probably be a window in which
| both oldpath and newpath refer to the file being renamed.