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+YE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG+vzHun1EqMxyQg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS (Michael Paquier <michael@paquier.xyz>) |
| Список | pgsql-hackers |
On 29 March 2018 at 10:30, Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Mar 27, 2018 at 11:53:08PM -0400, Tom Lane wrote:
> Craig Ringer <craig@2ndquadrant.com> writes:
>> TL;DR: Pg should PANIC on fsync() EIO return.
>
> Surely you jest.
Any callers of pg_fsync in the backend code are careful enough to check
the returned status, sometimes doing retries like in mdsync, so what is
proposed here would be a regression.
I covered this in my original post.
Yes, we check the return value. But what do we do about it? For fsyncs of heap files, we ERROR, aborting the checkpoint. We'll retry the checkpoint later, which will retry the fsync(). **Which will now appear to succeed** because the kernel forgot that it lost our writes after telling us the first time. So we do check the error code, which returns success, and we complete the checkpoint and move on.
But we only retried the fsync, not the writes before the fsync.
The problem is that we keep retrying checkpoints *without* repeating the writes leading up to the checkpoint, and retrying fsync.
I don't pretend the kernel behaviour is sane, but we'd better deal with it anyway.
--
В списке pgsql-hackers по дате отправления: