On 21/03/15 19:28, Jaime Casanova wrote:
On Fri, Mar 20, 2015 at 11:29 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
On Sat, Mar 21, 2015 at 2:47 AM, Peter Geoghegan <p...@heroku.com> wrote:
On Fri, Mar 20, 2015 at 9:52 AM, Joshua D. Drake <j...@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...
I fought to remove fsync before so i understand JD concerns. and yes,
i have seen fsync=off in the field too...
what about not removing it but not showing it in postgresql.conf? as a
side note, i wonder why trace_sort is not in postgresql.conf...
other option is to make it a compile setting, that why if you want to
have it you need to compile and postgres' developers do that routinely
anyway
-1
Personally I'm against hiding *any* settings. Choosing sensible defaults
- yes! Hiding them - that reeks of secret squirrel nonsense and overpaid
Oracle dbas that knew the undocumented settings for various
capabilities. I think/hope that no open source project will try to
emulate that meme!
Regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
