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 20160317150312.cqikwmqp2qf4a6ic@alap3.anarazel.de
Whole thread Raw
In response to Re: silent data loss with ext4 / all current versions  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: silent data loss with ext4 / all current versions
Re: silent data loss with ext4 / all current versions
List pgsql-hackers
On 2016-03-17 23:05:42 +0900, Michael Paquier wrote:
> > Are you working on a fix for pg_rewind? Let's go with initdb -S in a
> > first iteration, then we can, if somebody is interest enough, work on
> > making this nicer in master.
> 
> I am really -1 for this approach. Wrapping initdb -S with
> find_other_exec is intrusive in back-branches knowing that all the I/O
> write operations manipulating file descriptors go through file_ops.c,
> and we actually just need to fsync the target file in
> close_target_file(), making the fix being a 7-line patch, and there is
> no need to depend on another binary at all. The backup label file, as
> well as the control file are using the same code path in file_ops.c...
> And I like simple things :)

This is a *much* more expensive approach though. Doing the fsync
directly after modifying the file. One file by one file. Will usually
result in each fsync blocking for a while.

In comparison of doing a flush and then an fsync pass over the whole
directory will usually only block seldomly. The flushes for all files
can be combined into very few barrier operations.

Besides that, you're not syncing the directories, despite
open_target_file() potentially creating the directory.


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Performance degradation in commit ac1d794
Next
From: Corey Huinker
Date:
Subject: Re: Re: Add generate_series(date,date) and generate_series(date,date,integer)