On Thu, Mar 17, 2016 at 11:03 AM, Andres Freund <andres@anarazel.de> wrote:
> 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.
Yeah, I'm pretty sure this was discussed when initdb -S went in. I
think reusing that is a good idea.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company