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