Re: silent data loss with ext4 / all current versions - Mailing list pgsql-hackers

From Andres Freund
Subject Re: silent data loss with ext4 / all current versions
Date
Msg-id 20160307063840.ooafi4sjhexygdcz@alap3.anarazel.de
Whole thread Raw
In response to Re: silent data loss with ext4 / all current versions  (Andres Freund <andres@anarazel.de>)
Responses Re: silent data loss with ext4 / all current versions
List pgsql-hackers
Hi,

On 2016-03-05 19:54:05 -0800, Andres Freund wrote:
> I started working on this; delayed by taking longer than planned on the
> logical decoding stuff (quite a bit complicated by
> e1a11d93111ff3fba7a91f3f2ac0b0aca16909a8).  I'm not very happy with the
> error handling as it is right now.  For one, you have rename_safe return
> error codes, and act on them in the callers, but on the other hand you
> call fsync_fname which always errors out in case of failure.  I also
> don't like the new messages much.
>
> Will continue working on this tomorrow.

So, here's my current version of this. I've not performed any testing
yet, and it's hot of the press. There's some comment smithing
needed. But otherwise I'm starting to like this.

Changes:
* renamed rename_safe to durable_rename
* renamed replace_safe to durable_link_or_rename (there was never any
  replacing going on)
* pass through elevel to the underlying routines, otherwise we could
  error out with ERROR when we don't want to. That's particularly
  important in case of things like InstallXLogFileSegment().
* made fsync_fname use fsync_fname_ext, add 'accept permission errors'
  param
* have walkdir call a wrapper, to add ignore_perms param

What do you think?

I sure wish we had the recovery testing et al. in all the back
branches...

- Andres

Attachment

pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: Re: How can we expand PostgreSQL ecosystem?
Next
From: Amit Langote
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.