Re: Remove fsync ON/OFF as a visible option?
От | Josh Berkus |
---|---|
Тема | Re: Remove fsync ON/OFF as a visible option? |
Дата | |
Msg-id | 550DDA5B.1020507@agliodbs.com обсуждение исходный текст |
Ответ на | Remove fsync ON/OFF as a visible option? ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: Remove fsync ON/OFF as a visible option?
(Andres Freund <andres@2ndquadrant.com>)
Re: Remove fsync ON/OFF as a visible option? (Euler Taveira <euler@timbira.com.br>) |
Список | pgsql-hackers |
On 03/20/2015 09:29 PM, Michael Paquier wrote: > On Sat, Mar 21, 2015 at 2:47 AM, Peter Geoghegan <pg@heroku.com> wrote: >> On Fri, Mar 20, 2015 at 9:52 AM, Joshua D. Drake <jd@commandprompt.com> wrote: >>> There are just as many people that are running with scissors that are now >>> running (or attempting to run) our elephant in production. Does it make >>> sense to remove fsync (and possibly full_page_writes) from such a visible >>> place as postgresql.conf? >> >> -1 >> >> Anyone turning off fsync without even for a moment considering the >> consequences has only themselves to blame. I can't imagine why you'd >> want to remove full_page_writes or make it less visible either, since >> in principle it ought to be perfectly fine to turn it off in >> production once its verified as safe. > > -1 for its removal as well. It is still useful for developers to > emulate CPU-bounded loads... Coincidentally, I am just at this moment performance testing "running with scissors mode" for PostgreSQL on AWS. When intentional, this mode is useful for spinning up lots of read-only replicas which are intended mainly as cache support, something I've done at various dot-coms. So, -1 on removing the setting; it is useful to some users. Further, full_page_writes=off is supposedly safe on any copy-on-write filesystem, such as ZFS. Since that can cut fsync time by as much as 30%, -1 to remove/hide that setting either. The proposal that we make certain settings "only available via ALTER SYSTEM" also doesn't make sense; ALTER SYSTEM isn't capable of writing any settings which aren't available in postgresql.conf. Now, I have *long* been an advocate that we should ship a "stripped" PostgreSQL.conf which has only the most commonly used settings, and leave the rest of the settings in the docs and share/postgresql/postgresql.conf.advanced. Here's my example of such a file, tailored to PostgreSQL 9.3: https://github.com/pgexperts/accidentalDBA/blob/master/vagrant/setup/postgres/postgresql.conf While we likely wouldn't want to ship all of the advice in the comments in that file (the calculations, in particular, have been questioned since they were last tested with PostgreSQL 8.3), that gives you an example of what a simple/mainstream pg.conf could look like. I would further advocate that that file be broken up into segments (resources, logging, connects, etc.) and placed in conf.d/ All that being said, what *actually* ships with PostgreSQL is up to the packagers, so anything we do with pg.conf will have a limited impact unless we get them on board with the idea. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Миша ТюринДата:
Сообщение: Re[2]: [HACKERS] Remove fsync ON/OFF as a visible option?