Re: Remove fsync ON/OFF as a visible option?

Поиск
Список
Период
Сортировка
От Euler Taveira
Тема Re: Remove fsync ON/OFF as a visible option?
Дата
Msg-id 550EE0FA.3080302@timbira.com.br
обсуждение исходный текст
Ответ на Re: Remove fsync ON/OFF as a visible option?  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Remove fsync ON/OFF as a visible option?  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
On 21-03-2015 17:53, Josh Berkus wrote:
> 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:
> 
+1. I agree that common used settings in a postgresql.conf file is
useful for newbies. How do we ship it?

(i) replace postgresql.conf with newbie.conf at $PGDATA;
(ii) let postgresql.conf alone and include newbie.conf at the end;
(iii) install newbie.conf at share directory and let packagers decide to
replace postgresql.conf with it or not;
(iv) install newbie.conf at share directory and add an option in initdb
to select it as postgresql.conf, say, --config=simple.

As a starting point, (i) could be too radical because some DBAs are used
to check that occasional parameter at postgresql.conf. (ii) will
advocate the newbie configuration file. However, do we want a new
configuration file? We already have two and another one could be very
confusing. The option (iii) will be effective if popular distributions
decided to use newbie.conf as postgresql.conf. An the last option is a
flexible way to install a basic configuration (and imo is the way to
satisfy those that want basic configuration file available). It also has
a way to extend that option to other setups like one-file-per-section or
developer-conf.

The downside of the proposed newbie.conf is that we need to maintain
another configuration file. During beta time, some parameters could be
added/removed to/from newbie.conf.

> https://github.com/pgexperts/accidentalDBA/blob/master/vagrant/setup/postgres/postgresql.conf
> 
Your example is an good resource for newbies. I would like to see an
archive section (separated from replication) and some more log options
(where is log_file_prefix and log_duration?). port? A ssl section?
track_function? That could have others but those are on my preference list.

> 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/
> 
IMHO too many files could confuse simple installations.

> 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.
> 
In my experience, packagers tend to follow the default postgresql.conf.
They don't add or remove parameters but replace values.


--   Euler Taveira                   Timbira - http://www.timbira.com.br/  PostgreSQL: Consultoria, Desenvolvimento,
Suporte24x7 e Treinamento
 



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Zero-padding and zero-masking fixes for to_char(float)
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: PATCH: numeric timestamp in log_line_prefix