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
|
Список | 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 по дате отправления: