From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Final(?) proposal for wal_sync_method changes |
Date: | 2010-12-07 17:11:46 |
Message-ID: | 201012071811.46740.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tuesday 07 December 2010 17:24:14 Tom Lane wrote:
> 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_direct
> open_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.
I vote for changing the order but not doing the O_DIRECT stuff on the
backbranches.
As I am not seeing myself or clients of mine ever using any O_*SYNC variant I
am not strongly opionated about what to do there. But I guess adding those two
variants is not really much work.
Thanks,
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2010-12-07 17:30:35 | Re: Feature request - CREATE TYPE ... WITH OID = oid_number. |
Previous Message | Jeff Janes | 2010-12-07 17:09:59 | Re: Instrument checkpoint sync calls |