Re: Remove fsync ON/OFF as a visible option?
От | Jim Nasby |
---|---|
Тема | Re: Remove fsync ON/OFF as a visible option? |
Дата | |
Msg-id | 55146518.30906@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Remove fsync ON/OFF as a visible option? (Jeff Janes <jeff.janes@gmail.com>) |
Список | pgsql-hackers |
On 3/25/15 8:35 PM, Jeff Janes wrote: > On Wed, Mar 25, 2015 at 12:45 PM, Jim Nasby <Jim.Nasby@bluetreble.com > <mailto:Jim.Nasby@bluetreble.com>> wrote: > > > I see 3 settings that allow people to accidentally shoot themselves > in the foot; fsync, wal_sync_method and full_page_writes. > > How about just grouping those 3 together with a bulk disclaimer > along the lines of "The following 3 settings are dangerous. Use at > your own risk, and read the docs first."? That would also allow us > to just remove the comments about what the settings do; if you don't > already know you certainly shouldn't be touching them! :) > > > But one of these things is not like the other. Any supported (i.e. non > fatal erroring) setting of wal_sync_method *should* always be safe > (although may be inefficient) if the underlying kernel, RAID controller, > hard drives, and fs fulfill their pledges. It is hard to document every > known liar in this regard. About the best you can do, short of > pull-the-plug test on a massive scale, is to run pg_fsync_test and > assuming that any result inconsistent with the RPM of the spinning rust > is obviously unsafe. Unfortunately that doesn't rule out the possibility > that something is both unsafe and gratuitously slow. I agree, but the reason I include this setting as dangerous is you really don't know what you're getting into once you move past fsync unless you actually study it and/or do testing. To me, that makes that setting dangerous. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: