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 AF90CC2E-E990-4E5B-BB06-EB3F423E5879@thebuild.com
обсуждение исходный текст
Ответ на Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS  (Andres Freund <andres@anarazel.de>)
Ответы Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
> On Apr 8, 2018, at 16:16, Andres Freund <andres@anarazel.de> wrote:
> We don't panic that way when getting IO
> errors during reads either, and they're more likely to be persistent
> than errors during writes (because remapping on storage layer can fix
> issues, but not during reads).

There is a distinction to be drawn there, though, because we immediately pass an error back to the client on a read,
buta write problem in this situation can be masked for an extended period of time. 

That being said...

> There's a lot of not so great things here, but I don't think there's any
> need to panic.

No reason to panic, yes.  We can assume that if this was a very big persistent problem, it would be much more widely
reported. It would, however, be good to find a way to get the error surfaced back up to the client in a way that is not
justmonitoring the kernel logs. 

--
-- Christophe Pettus
   xof@thebuild.com



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Rewriting the test of pg_upgrade as a TAP test - take two