Re: Permanent settings

On Tue, Feb 19, 2008 at 02:59:44PM -0800, 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.

Ok, now I see the point. But does this really work in a scenario when the
user edits the config file himself? The order will likely be broken pretty
quickly anyway in that case...


> > > 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.

Oh, ok. Then I'm in agreement.


> > 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.

AFAIK, Apache doesn't document all it's parameters there. Or maybe it does
and the distributions generaelly cut it down? ;-)

//Magnus