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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
