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 20180404021428.GC25202@momjian.us
обсуждение исходный текст
Ответ на 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  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
On Tue, Apr  3, 2018 at 10:05:19PM -0400, Bruce Momjian wrote:
> On Wed, Apr  4, 2018 at 01:54:50PM +1200, Thomas Munro wrote:
> > I believe there were some problems of that nature (with various
> > twists, based on other concurrent activity and possibly different
> > fds), and those problems were fixed by the errseq_t system developed
> > by Jeff Layton in Linux 4.13.  Call that "bug #1".
> 
> So all our non-cutting-edge Linux systems are vulnerable and there is no
> workaround Postgres can implement?  Wow.

Uh, are you sure it fixes our use-case?  From the email description it
sounded like it only reported fsync errors for every open file
descriptor at the time of the failure, but the checkpoint process might
open the file _after_ the failure and try to fsync a write that happened
_before_ the failure.

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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: [HACKERS] Runtime Partition Pruning
Следующее
От: David Rowley
Дата:
Сообщение: Re: [HACKERS] Runtime Partition Pruning