| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: postgresql latency & bgwriter not doing its job |
| Date: | 2014-08-27 13:50:02 |
| Message-ID: | CAGTBQpbQK8i+U67eu3=amo=czpHG6tPX+RVRpg-sDRE6G3cycQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 27, 2014 at 10:20 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-08-27 10:17:06 -0300, Claudio Freire wrote:
>> > I think a somewhat smarter version of the explicit flushes in the
>> > hack^Wpatch I posted nearby is going to more likely to be successful.
>>
>>
>> That path is "dangerous" (as in, may not work as intended) if the
>> filesystem doesn't properly understand range flushes (ehem, like
>> ext3).
>
> The sync_file_range(SYNC_FILE_RANGE_WRITE) I used isn't a operation
> guaranteeing durability. And - afaik - not implemented in a file system
> specific manner. It just initiates writeback for individual pages. It
> doesn't cause barrier, journal flushes or anything to be issued. That's
> still done by the fsync() later.
>
> The big disadvantage is that it's a OS specific solution, but I don't
> think we're going to find anything that isn't in this area.
I guess it should work then.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-08-27 13:54:11 | Re: Hardening pg_upgrade |
| Previous Message | Fujii Masao | 2014-08-27 13:46:17 | Re: ALTER SYSTEM RESET? |