Re: Checkpoint not retrying failed fsync?

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Checkpoint not retrying failed fsync?
Дата
Msg-id CAEepm=21AfdkGTwaaWfde0J0u0ggmbP6TOO3pNB8tX8uSOTZ2w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Checkpoint not retrying failed fsync?  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: Checkpoint not retrying failed fsync?  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Does logical replication supports cross platform servers?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1