On Fri, Apr 08, 2022 at 09:00:36PM -0400, Robert Haas wrote: > On Fri, Apr 8, 2022 at 12:53 PM Nathan Bossart <nathandboss...@gmail.com> > 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.
Not always. For example, some old versions of MacOS have a non-atomic implementation of rename(), like prairiedog with 10.4. Even 10.5 does not handle atomicity as far as I call. In short, it looks like a bad idea to me to rely on this idea at all. Some FSes have their own way of handling things, as well, but I am not much into this world. Saying that, it would be nice to see durable_rename_excl() gone as it has created quite a bit of pain for us in the past years. -- Michael
signature.asc
Description: PGP signature
