Re: O_DSYNC broken on MacOS X?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: O_DSYNC broken on MacOS X?
Date: 2010-10-19 16:16:01
Message-ID: 201010191616.o9JGG1C22893@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

A.M. wrote:
>
> On Oct 19, 2010, at 11:22 AM, Bruce Momjian wrote:
>
> > Greg Smith wrote:
> >> A.M. wrote:
> >>> Perhaps a simpler tool could run a basic fsyncs-per-second test and prompt the DBA to check that the numbers are within the realm of possibility.
> >>>
> >>
> >> This is what the test_fsync utility that already ships with the database
> >> should be useful for. The way Bruce changed it to report numbers in
> >> commits/second for 9.0 makes it a lot easier to use for this purpose
> >> than it used to be. I think there's still some additional improvements
> >> that could be made there, but it's a tricky test to run accurately. The
> >
> > test_fsync was designed to test various things like whether several
> > open-sync writes are better than two write and an fsync, and whether you
> > can fsync data written on a different file descriptor. It is really a
> > catch-all test right now, not one specific for choosing sync methods.
>
> I am working on simplifying the test_fsync tool and making it a contrib function which can be run by the superuser based on the configured fsync method. That way, the list can ask a user to run it to report fsyncs-per-second for suspiciousness. The goal is to make it more accessible. I was also thinking about adding some notes along the lines of "Your drive fsync speed rates between a 5400 RPM SATA drive and a 7200 RPM SATA drive." or "Your drive fsync speed rates as high as RAM- your fsync method may be wrong."
>
> Currently, the test tool is not even compiled by default.
>
> Thoughts?

Agreed. Let me know if you have any questions.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-10-19 16:16:33 Re: Simplifying replication
Previous Message Alvaro Herrera 2010-10-19 16:13:44 Re: Extensions, this time with a patch