On 21/03/15 19:28, Jaime Casanova wrote:
> On Fri, Mar 20, 2015 at 11:29 PM, Michael Paquier
> <michael.paquier@gmail.com> 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...
>
> 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