On Wed, Aug 16, 2023 at 08:17:05AM -0700, Nathan Bossart wrote: > On Wed, Aug 16, 2023 at 08:10:10AM +0900, Michael Paquier wrote: >> + pg_log_error("could not synchronize file system for file \"%s\": >> %m", path); >> + (void) close(fd); >> + exit(EXIT_FAILURE); >> >> walkdir() reports errors and does not consider these fatal. Why the >> early exit()? > > I know it claims to, but fsync_fname() does exit when fsync() fails: > > returncode = fsync(fd); > > /* > * Some OSes don't allow us to fsync directories at all, so we can > ignore > * those errors. Anything else needs to be reported. > */ > if (returncode != 0 && !(isdir && (errno == EBADF || errno == EINVAL))) > { > pg_log_error("could not fsync file \"%s\": %m", fname); > (void) close(fd); > exit(EXIT_FAILURE); > } > > I suspect that the current code does not treat failures for things like > open() as fatal because it's likely due to a lack of permissions on the > file, but it does treat failures to fsync() as fatal because it is more > likely to indicate that ѕomething is very wrong. I don't know whether this > reasoning is sound, but I tried to match the current convention in the > syncfs() code.
Ah, it looks like this code used to treat fsync() errors as non-fatal, but it was changed in commit 1420617. I still find it a bit strange that some errors that prevent a file from being sync'd are non-fatal while others _are_ fatal, but that is probably a topic for another thread. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com