Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Дата
Msg-id 20180417213453.oks5q7wcpp7qgvht@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On 2018-04-17 17:29:17 -0400, Bruce Momjian wrote:
> Also, if we are relying on WAL, we have to make sure WAL is actually
> safe with fsync, and I am betting only the O_DIRECT methods actually
> are safe:
> 
>     #wal_sync_method = fsync                # the default is the first option
>                                             # supported by the operating system:
>                                             #   open_datasync
>                                      -->    #   fdatasync (default on Linux)
>                                      -->    #   fsync
>                                      -->    #   fsync_writethrough
>                                             #   open_sync
> 
> I am betting the marked wal_sync_method methods are not safe since there
> is time between the write and fsync.

Hm? That's not really the issue though? One issue is that retries are
not necessarily safe in buffered IO, the other that fsync might not
report an error if the fd was closed and opened.

O_DIRECT is only used if wal archiving or streaming isn't used, which
makes it pretty useless anyway.

Greetings,

Andres Freund


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Append's first_partial_plan