Date: Wed, 16 Aug 2023 08:23:25 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
	Thomas Munro <thomas.munro@gmail.com>,
	David Steele <david@pgmasters.net>,
	Fujii Masao <masao.fujii@oss.nttdata.com>,
	Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>,
	Michael Brown <michael.brown@discourse.org>,
	pgsql-hackers@postgresql.org
Subject: Re: should frontend tools use syncfs() ?
Message-ID: <20230816152325.GC2651383@nathanxps13>
References: <20210930004340.GM831@telsasoft.com>
 <YVUz0Ay9KshniWBe@paquier.xyz>
 <20220413115412.GM26620@telsasoft.com>
 <20230729214010.GA189456@nathanxps13>
 <20230731175138.GA432880@nathanxps13>
 <20230731183946.GB537853@nathanxps13>
 <20230801163707.GA862840@nathanxps13>
 <20230808200606.GA1384393@nathanxps13>
 <ZNwF0u/89JFUOQiM@paquier.xyz>
 <20230816151705.GB2651383@nathanxps13>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20230816151705.GB2651383@nathanxps13>
Archived-At: 
 <https://www.postgresql.org/message-id/20230816152325.GC2651383%40nathanxps13>
Precedence: bulk

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