On Fri, Mar 18, 2016 at 12:03 AM, Andres Freund <and...@anarazel.de> wrote: > 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.
Hm... OK. I'd really like to keep the run of pg_rewind minimal as well if possible. So here you go. -- Michael
0001-Close-file-descriptor-associated-to-backup_label-cor.patch
Description: binary/octet-stream
0002-fsync-properly-files-modified-by-pg_rewind.patch
Description: binary/octet-stream
0003-Avoid-potential-data-loss-in-pg_receivexlog.patch
Description: binary/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
