Re: Final(?) proposal for wal_sync_method changes
От | Andres Freund |
---|---|
Тема | Re: Final(?) proposal for wal_sync_method changes |
Дата | |
Msg-id | 201012071811.46740.andres@anarazel.de обсуждение исходный текст |
Ответ на | Final(?) proposal for wal_sync_method changes (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: