Hi,
On 2019-05-23 10:46:02 -0700, Mark Dilger wrote:
> I have seen other lengthy discussions about fsync semantics, and if this
> question is being addressed there, this question might not be relevant.
>
> Two calls to durable_unlink at log level DEBUG1 are ignoring the
> return value. Other calls at ERROR and FATAL are likewise ignoring
> the return value, though those make perfect sense to me. There may
> be a reason why logging a debug message inside durable_unlink and
> continuing along is safe, but it is not clear from the structure of the
> code.
>
> In InstallXLogFileSegment, durable_unlink(path, DEBUG1) is called
> without the return value being checked followed by a call to
> durable_link_or_rename, and perhaps that second call works
> whether the durable_unlink succeeded or failed, but the logic of that is
> not at all clear.
>
> In do_pg_stop_backup, durable_unlink(TABLESPACE_MAP, DEBUG1)
> is similarly called without the return value being checked.
>
> This code appears to have been changed in
> 1b02be21f271db6bd3cd43abb23fa596fcb6bac3.
>
> Is this code safe against fsync failures? If so, can I get an explanation
> that I might put into a code comment patch?
What's the danger you're thinking of here? The issue with ignoring fsync
failures is that it could be the one signal about data corruption we get
for a write()/fsync() that failed - i.e. that durability cannot be
guaranteed. But we don't care about the file contents of those files.
Greetings,
Andres Freund