On Thu, Mar 17, 2016 at 11:03 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
