Re: Permanent settings - Mailing list pgsql-hackers

One idea would be to remove duplicate postgresql.conf appended entries
on server start.

---------------------------------------------------------------------------

Josh Berkus wrote:
> Magnus,
> 
> > That's basically "include" but with a different name, no?
> 
> Yes.  FWIW, I seem to be lagged about 3 hours on -hackers. 
> 
> > Why do you need to split it in two columns, and what would go in what
> > column?
> 
> Current data:
> 
> postgres=# select name, category from pg_settings;
>           name           |                             category
> -------------------------+-------------------------------------------------------------------
>  allow_system_table_mods | Developer Options
>  archive_command         | Write-Ahead Log / Settings
>  archive_mode            | Write-Ahead Log / Settings
>  archive_timeout         | Write-Ahead Log / Settings
> 
> How it should be:
> 
> postgres=# select name, category, subcategory from pg_settings;
>           name           |      category      |         subcategory
> -------------------------+------------------------------------------------
>  allow_system_table_mods | Developer Options  |
>  archive_command         | Write-Ahead Log    | Settings
>  archive_mode            | Write-Ahead Log    | Settings
>  archive_timeout         | Write-Ahead Log    | Settings
> 
> this would then allow us to do this:
> 
> select * from pg_settings_categories
> name                 order
> Developer Options        37
> Write-Ahead Log            11
> 
> select * from pg_settings_subcategories
> name                category    
> allow_system_table_mods        Developer Options
> archive_command            Write-Ahead Log
> archive_mode            Write-Ahead Log
> 
> and then generate a file which looks like this:
> 
> # == Write-Ahead Log ==
> # Settings
> 
>     archive_command    = '/bin/rsync'
>     archive_mode = 'on'
> 
> # Fsync
>     
>     fsync = on
>     wal_buffers = 8mb
> 
> ... etc.
> 
> This would allow the automatically generated version to be readable and 
> searchable, if not quite as narrative as the present postgresql.conf.
> 
> 
> >
> > > 3) have command line config write to postgresql.auto.conf, dumping the
> > > whole of pg_settings organized with headings in categories order.
> >
> > Don't get what you mean here. You mean you want a commandline tool to
> > generate a config file from pg_settings?
> 
> I meant from the SQL command line.
> 
> > Another question completely, but related, is if it's actually the right
> > thing to use postgresql.conf to write documentation. The way it is now
> > we basically add all new config options to postgresql.conf.sample along
> > with a comment that is the documentation. A different approach would be
> > to only include the very most common settings, or possibly even only
> > those that initdb sets to something non-default, in
> > postgresql.conf.sample, and have the rest only added when they're
> > actually used. Documentation really belongs in the documentation, after
> > all...
> 
> Yeah, we've taken an Apache-like approach of including heavy comments on 
> the settings in the settings file itself.  Unfortunately, I think changing 
> that practice at this point would alienate a bunch of users.
> 
> -- 
> --Josh
> 
> Josh Berkus
> PostgreSQL @ Sun
> San Francisco
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +