Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
От | Bruce Momjian |
---|---|
Тема | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
Дата | |
Msg-id | 20180404142547.GA10462@momjian.us обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-hackers |
On Wed, Apr 4, 2018 at 10:09:09PM +0800, Craig Ringer wrote: > On 4 April 2018 at 22:00, Craig Ringer <craig@2ndquadrant.com> wrote: > > > It's the error reporting issues around closing and reopening files with > outstanding buffered I/O that's really going to hurt us here. I'll be > expanding my test case to cover that shortly. > > > > Also, just to be clear, this is not in any way confined to xfs and/or lvm as I > originally thought it might be. > > Nor is ext3/ext4's errors=remount-ro protective. data_err=abort doesn't help > either (so what does it do?). Anthony Iliopoulos reported in this thread that errors=remount-ro is only affected by metadata writes. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления: