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

Поиск
Список
Период
Сортировка
От Christophe Pettus
Тема Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Дата
Msg-id 80B1A286-A073-417A-8968-605FE4A11B7B@thebuild.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  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
> On Apr 8, 2018, at 03:30, Craig Ringer <craig@2ndQuadrant.com> wrote:
>
> These are way more likely than bit flips or other storage level corruption, and things that we previously expected to
detectand fail gracefully for. 

This is definitely bad, and it explains a few otherwise-inexplicable corruption issues we've seen.  (And great work
trackingit down!)  I think it's important not to panic, though; PostgreSQL doesn't have a reputation for horrible data
integrity. I'm not sure it makes sense to do a major rearchitecting of the storage layer (especially with pluggable
storagecoming along) to address this.  While the failure modes are more common, the solution (a PITR backup) is one
thatan installation should have anyway against media failures. 

--
-- Christophe Pettus
   xof@thebuild.com



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

Предыдущее
От: Teodor Sigaev
Дата:
Сообщение: Re: WIP: Covering + unique indexes.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WIP: a way forward on bootstrap data