Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
От | Thomas Munro |
---|---|
Тема | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
Дата | |
Msg-id | CAEepm=2JnwtkZ1PAuPMx=UtG21VPQFfRrVzVTWjEPQmYR-zyng@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS (Michael Paquier <michael@paquier.xyz>) |
Ответы |
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 Thu, Mar 29, 2018 at 3:30 PM, Michael Paquier <michael@paquier.xyz> wrote: > On Tue, Mar 27, 2018 at 11:53:08PM -0400, Tom Lane wrote: >> Craig Ringer <craig@2ndquadrant.com> writes: >>> TL;DR: Pg should PANIC on fsync() EIO return. >> >> Surely you jest. > > Any callers of pg_fsync in the backend code are careful enough to check > the returned status, sometimes doing retries like in mdsync, so what is > proposed here would be a regression. Craig, is the phenomenon you described the same as the second issue "Reporting writeback errors" discussed in this article? https://lwn.net/Articles/724307/ "Current kernels might report a writeback error on an fsync() call, but there are a number of ways in which that can fail to happen." That's... I'm speechless. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: