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.

Attachment: 0001-Close-file-descriptor-associated-to-backup_label-cor.patch
Description: binary/octet-stream

Attachment: 0002-fsync-properly-files-modified-by-pg_rewind.patch
Description: binary/octet-stream

Attachment: 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:

Reply via email to