fsync failure in durable_unlink ignored in xlog.c?

From: Mark Dilger <hornschnorter(at)gmail(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: fsync failure in durable_unlink ignored in xlog.c?
Date: 2019-05-23 17:46:02
Message-ID: CAE-h2TpkQsnRrKr=sdR_nzBHRO0eeL5Qt0wR9RGyz-2VZAJBtA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hackers,

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?

mark

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-23 17:46:15 Re: FullTransactionId changes are causing portability issues
Previous Message Tom Lane 2019-05-23 17:43:11 Re: Why could GEQO produce plans with lower costs than the standard_join_search?