Re: Checkpoint not retrying failed fsync? - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Checkpoint not retrying failed fsync?
Date
Msg-id CAEepm=21AfdkGTwaaWfde0J0u0ggmbP6TOO3pNB8tX8uSOTZ2w@mail.gmail.com
Whole thread Raw
In response to Re: Checkpoint not retrying failed fsync?  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: Checkpoint not retrying failed fsync?
List pgsql-hackers
On Sun, Apr 8, 2018 at 9:17 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> New patch attached.

For Linux users (read: almost all users) this patch on its own is a
bit like rearranging the deck chairs on the Titanic.  Because retrying
on failure is useless, among other problems, Craig and Andres are
working on converting IO errors into PANICs and overhauling the
request queue[1].

I was about to mark this patch "rejected" and forget about it, since
Craig's patch makes it redundant.  But then I noticed that Craig's
patch doesn't actually remove the retry behaviour completely: it
promotes only EIO and ENOSPC to PANIC.  If you somehow manage to get
any other errno from fsync(), the checkpoint will fail and you'll be
exposed to this bug: PostgreSQL forgets that the segment was dirty, so
the next checkpoint might fsync nothing at all and then bogusly report
success.  So, I think either Craig's patch should PANIC on *any* error
from fsync(), or we should commit this patch too so that we remember
which segments are dirty next time around.

[1]
https://www.postgresql.org/message-id/flat/CAMsr%2BYFPeKVaQ57PwHqmRNjPCPABsdbV%3DL85he2dVBcr6yS1mA%40mail.gmail.com

-- 
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Does logical replication supports cross platform servers?
Next
From: Michael Paquier
Date:
Subject: Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1