From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, dpage(at)pgadmin(dot)org, Guillaume Lelarge <guillaume(dot)lelarge(at)dalibo(dot)com> |
Subject: | Re: silent data loss with ext4 / all current versions |
Date: | 2016-03-18 06:08:32 |
Message-ID: | CAB7nPqRmM+CX6bVxw0Y7mMVGMFj1S8kwhevt8TaP83yeFRfbXA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 18, 2016 at 12:03 AM, Andres Freund <andres(at)anarazel(dot)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
Attachment | Content-Type | Size |
---|---|---|
0001-Close-file-descriptor-associated-to-backup_label-cor.patch | binary/octet-stream | 924 bytes |
0002-fsync-properly-files-modified-by-pg_rewind.patch | binary/octet-stream | 3.6 KB |
0003-Avoid-potential-data-loss-in-pg_receivexlog.patch | binary/octet-stream | 4.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-03-18 06:13:15 | Re: insufficient qualification of some objects in dump files |
Previous Message | Thomas Munro | 2016-03-18 05:30:35 | Re: Proposal: BSD Authentication support |