Re: Permanent settings - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Permanent settings
Date
Msg-id 200802191459.45179.josh@agliodbs.com
Whole thread Raw
In response to Re: Permanent settings  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Permanent settings  (Bruce Momjian <bruce@momjian.us>)
Re: Permanent settings  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
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 |
DeveloperOptionsarchive_command         | Write-Ahead Log / Settingsarchive_mode            | Write-Ahead Log /
Settingsarchive_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    | Settingsarchive_mode            | Write-Ahead Log    |
Settingsarchive_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'

# Fsyncfsync = onwal_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


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: pg_dump additional options for performance
Next
From: Bruce Momjian
Date:
Subject: Re: Permanent settings