Re: fsync failure in durable_unlink ignored in xlog.c?

From: Mark Dilger <hornschnorter(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, 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: Re: fsync failure in durable_unlink ignored in xlog.c?
Date: 2019-05-23 18:14:13
Message-ID: CAE-h2To3MTknBoLhvTVy5QcJxwdJR2uLEhg4wTwdTBe+yHYy2g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 23, 2019 at 11:07 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2019-05-23 10:46:02 -0700, Mark Dilger wrote:
> >> 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.
>
> Hmm ... if we don't care, why are we issuing an fsync at all?

Tom's question is about as far as my logic went. It seemed the fsync
must be important, or the author of this code wouldn't have put such
an expensive operation in that spot, and if so, then how can it be safe
to ignore whether the fsync returned an error. Beyond that, I do not
have a specific danger in mind.

mark

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-05-23 18:18:20 Re: fsync failure in durable_unlink ignored in xlog.c?
Previous Message Tom Lane 2019-05-23 18:06:57 Re: fsync failure in durable_unlink ignored in xlog.c?