Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
От | Greg Stark |
---|---|
Тема | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
Дата | |
Msg-id | CAM-w4HNH71T0chk-7jx9_VLMcz6iY-NiSn5xgCcT2UJzP9dQsg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
Список | pgsql-hackers |
On 10 April 2018 at 02:59, Craig Ringer <craig@2ndquadrant.com> wrote: > Nitpick: In most cases the kernel reserves disk space immediately, > before returning from write(). NFS seems to be the main exception > here. I'm kind of puzzled by this. Surely NFS servers store the data in the filesystem using write(2) or the in-kernel equivalent? So if the server is backed by a filesystem where write(2) preallocates space surely the NFS server must behave as if it'spreallocating as well? I would expect NFS to provide basically the same set of possible failures as the underlying filesystem (as long as you don't enable nosync of course). -- greg
В списке pgsql-hackers по дате отправления: