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

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Дата
Msg-id CAMsr+YFFYO1eHTGzT1wnoRW6L_PmP8MDFhbcdVBjBKQSF9fkYw@mail.gmail.com
обсуждение исходный текст
Ответ на 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  (Antonis Iliopoulos <ailiop@altatus.com>)
Список pgsql-hackers
On 4 April 2018 at 22:25, Bruce Momjian <bruce@momjian.us> wrote:
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.

Yep, I gathered. I was referring to data_err.  

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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

Предыдущее
От: Dmitry Ivanov
Дата:
Сообщение: Re: new function for tsquery creartion
Следующее
От: Aleksandr Parfenov
Дата:
Сообщение: Re: new function for tsquery creartion