Final(?) proposal for wal_sync_method changes - Mailing list pgsql-hackers

From Tom Lane
Subject Final(?) proposal for wal_sync_method changes
Date
Msg-id 23293.1291739054@sss.pgh.pa.us
Whole thread Raw
Responses Re: Final(?) proposal for wal_sync_method changes
Re: Final(?) proposal for wal_sync_method changes
List pgsql-hackers
After reviewing the two ongoing threads about fixing the wal_sync_method
fiasco, I think there is general agreement on these two points:

1. open_datasync shouldn't be the default choice
2. O_DIRECT shouldn't be forcibly bundled in with O_DSYNC/O_SYNC

What I suggest we do about the latter is to invent two new 
wal_sync_method values,open_datasync_directopen_sync_direct
which are defined only on platforms that define O_DIRECT (and O_DSYNC
or O_SYNC respectively).  That puts it in the hands of the DBA whether
we try to use O_DIRECT or not.  We'll still keep the hard-wired
optimization of disabling O_DIRECT when archiving or walreceiver are
active.

Dropping open_datasync as the first-choice default is something we have
to back-patch, but I'm less sure about it being a good idea to
back-patch the rearrangement of O_DIRECT management.  Somebody who'd
explicitly specified open_sync or open_datasync as wal_sync_method
would find its behavior changing under him, which might be bad.

Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_execute_from_file review
Next
From: Tom Lane
Date:
Subject: Re: pg_execute_from_file review