Re: should frontend tools use syncfs() ?

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