Re: Add default_val to pg_settings - Mailing list pgsql-hackers

On Tue, 2008-09-16 at 00:10 -0400, Greg Smith wrote:

> Attached is an updated and separate version of my patch exposing the 
> internal GUC boot_val as default_val, which failed to attach itself to the 
> already committed changes to the pg_settings view.
> 
> Brief reminder of what it does:
> 
> postgres=# select name,setting,default_val from pg_settings where name='shared_buffers';
>        name      | setting | default_val
> ----------------+---------+-------------
>   shared_buffers | 4096    | 1024
> 
> General justification for this change with a longer example is at 
> http://archives.postgresql.org/pgsql-hackers/2008-09/msg00233.php
> 
> Based on feedback the first time around, I updated the documentation for 
> this column to read "Default value assumed at server startup if the 
> parameter is not otherwise set".
> 
> Would only take a quick search/replace of the patch to change 
> "default_val" to something else if there are still any objections there. 
> "boot_val" is another candidate name, I feel that would make the purpose 
> of the column less obvious to users of pg_settings even if it is more 
> correct. I'm really more concerned about the feature than exactly what 
> it's named though. I didn't bother to expose the reset_val since I can't 
> think of any obvious use cases for wanting to know it.

We have an RESET command which "returns parameter to its default
setting". But what this means is "return it to the value set in current
the postgresql.conf, if overriden therein from its default value". So it
would be useful to have a column that meant "if I run the RESET command
it would return me to this value".

The boot value is only interesting when the "source" column of
pg_settings is "default". In all other cases it is a misleading value,
AFAICS. It would be accurate in sessions that have not run SET, or have
just issued RESET ALL, but we have no way of knowing whether that is the
case or not.

I would suggest we either alter pg_settings so that we display value
*only* when source=default (set NULL otherwise) or we do some extra work
to derive what the setting would be if we ran RESET. The latter would be
preferred approach.

So column name boot_val seems most correct currently, but not very
useful. If we can make the changes above, then I'd stick with
default_val.

I like the concept very much though so please don't take my words as
opposition. *This* patch should not be applied, but a similar one could
and should be.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support