Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+ - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+
Date
Msg-id 4CFD82A2.3040405@agliodbs.com
Whole thread Raw
In response to Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+  (Greg Smith <greg@2ndquadrant.com>)
Responses Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+
List pgsql-hackers
On 12/5/10 2:12 PM, Greg Smith wrote:
> Josh Berkus wrote:
>> I modified test_fsync in two ways to run this; first, to make it support
>> O_DIRECT, and second to make it run in the *current* directory.
>
> Patch please?  I agree with the latter change; what test_fsync does is
> surprising.

Attached.

Making it support O_DIRECT would be possible but more complex; I don't
see the point unless we think we're going to have open_sync_with_odirect
as a seperate option.

> I suggested a while ago that we refactor test_fsync to use a common set
> of source code as the database itself for detecting things related to
> wal_sync_method, perhaps just extract that whole set of DEFINE macro
> logic to somewhere else.  That happened at a bad time in the development
> cycle (right before a freeze) and nobody ever got back to the idea
> afterwards.  If this code is getting touched, and it's clear it is in
> some direction, I'd like to see things change so it's not possible for
> the two to diverge again afterwards.

I don't quite follow you.  Maybe nobody else did last time, either.

--
                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.
                                     http://www.pgexperts.com

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WIP patch for parallel pg_dump
Next
From: Steve Singer
Date:
Subject: Re: We really ought to do something about O_DIRECT and data=journalled on ext4