Обсуждение: Add default_val to pg_settings
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. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
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
Simon Riggs <simon@2ndQuadrant.com> writes:
> 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.
Right, this is why I was complaining that the view should expose the
reset_val. Greg's opinion that only boot_val is needed seems to be
focused entirely on DBAs or tools for manipulating postgresql.conf ---
the only reason you'd want to know boot_val is to know "what will happen
if I remove this setting from postgresql.conf?". For ordinary users
boot_val is useless information, but reset_val could be interesting.
> 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.
Trying to make one column serve both masters sounds hopelessly confusing
to me; it would essentially make it useless for *both* sets of users,
because neither would know whether the value they're seeing is the one
they need.
regards, tom lane
Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: >> 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. > > Right, this is why I was complaining that the view should expose the > reset_val. Greg's opinion that only boot_val is needed seems to be > focused entirely on DBAs or tools for manipulating postgresql.conf --- > the only reason you'd want to know boot_val is to know "what will happen > if I remove this setting from postgresql.conf?". For ordinary users > boot_val is useless information, but reset_val could be interesting. If both are interesting to different audiences, perhaps we should be exposing both as separate columns? >> 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. > > Trying to make one column serve both masters sounds hopelessly confusing > to me; it would essentially make it useless for *both* sets of users, > because neither would know whether the value they're seeing is the one > they need. It sounds like you are making the case for what I write above? Having one column named reset_val and one named boot_val should work, no? //Magnus
On Thu, 2008-09-25 at 14:42 +0200, Magnus Hagander wrote: > If both are interesting to different audiences, perhaps we should be > exposing both as separate columns? That seems best. It will make things much clearer. > Having > one column named reset_val and one named boot_val should work, no? Yes, those names seem very appropriate to me. Finding the reset_val isn't that tough, IIRC the way the guc assignment works with its "doit" flag. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
Simon Riggs wrote: > On Thu, 2008-09-25 at 14:42 +0200, Magnus Hagander wrote: >> Having >> one column named reset_val and one named boot_val should work, no? > > Yes, those names seem very appropriate to me. > > Finding the reset_val isn't that tough, IIRC the way the guc assignment > works with its "doit" flag. > I haven't looked at the code.. but there is actually a field in the struct called reset_val. It may not be usable, or you may have just missed it? //Magnus
Magnus Hagander <magnus@hagander.net> writes:
> It sounds like you are making the case for what I write above? Having
> one column named reset_val and one named boot_val should work, no?
Well, that's what I've been saying right along, but the previous
discussion was all about what to call the columns ...
regards, tom lane
On Thu, 2008-09-25 at 14:52 +0200, Magnus Hagander wrote: > Simon Riggs wrote: > > On Thu, 2008-09-25 at 14:42 +0200, Magnus Hagander wrote: > >> Having > >> one column named reset_val and one named boot_val should work, no? > > > > Yes, those names seem very appropriate to me. > > > > Finding the reset_val isn't that tough, IIRC the way the guc assignment > > works with its "doit" flag. > I haven't looked at the code.. but there is actually a field in the > struct called reset_val. It may not be usable, or you may have just > missed it? Yah, missed it. Cool, even easier ;-) -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
On Thu, 2008-09-25 at 09:15 -0400, Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: > > It sounds like you are making the case for what I write above? Having > > one column named reset_val and one named boot_val should work, no? > > Well, that's what I've been saying right along, but the previous > discussion was all about what to call the columns ... Sorry Tom, I meant I was agreeing with both of you, not just Magnus. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
On Thu, 25 Sep 2008, Simon Riggs wrote: > 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. Since getting the value out when the source!=default is exactly the point for the applications I was talking about, I'll rewrite the patch to expose the reset_val as well and resubmit shortly. Thanks for the feedback, your comments helped clarify the use-case for reset_val a bit better for me and I'll be sure to document the two columns appropriately. One perspective I don't get to see very often is that of a regular user adjusting their settings. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Thu, 25 Sep 2008, Simon Riggs wrote:
> So it would be useful to have a column that meant "if I run the RESET
> command it would return me to this value".
Patch v3 attached that exposes boot_val and reset_val. The docs for the
latter link to the RESET command page for details.
Sample, with default_text_search_config snipped to fit the rest into a
reasonable width:
# select name,setting,reset_val,boot_val from pg_settings where
setting!=boot_val or setting!=reset_val;
name | setting | reset_val | boot_val
-----------------------+--------------------+--------------+---------
archive_command | (disabled) | |
client_encoding | UTF8 | UTF8 | SQL_ASCII
lc_collate | en_US.UTF-8 | en_US.UTF-8 | C
lc_ctype | en_US.UTF-8 | en_US.UTF-8 | C
lc_messages | en_US.UTF-8 | en_US.UTF-8 |
lc_monetary | en_US.UTF-8 | en_US.UTF-8 | C
lc_numeric | en_US.UTF-8 | en_US.UTF-8 | C
lc_time | en_US.UTF-8 | en_US.UTF-8 | C
log_timezone | US/Eastern | US/Eastern | UNKNOWN
max_fsm_pages | 204800 | 204800 | 20000
max_stack_depth | 2048 | 2048 | 100
server_encoding | UTF8 | UTF8 | SQL_ASCII
shared_buffers | 4096 | 4096 | 1024
TimeZone | US/Eastern | US/Eastern | UNKNOWN
timezone_abbreviations | Default | Default | UNKNOWN
transaction_isolation | read committed | default |
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Greg Smith wrote: > On Thu, 25 Sep 2008, Simon Riggs wrote: > >> So it would be useful to have a column that meant "if I run the RESET >> command it would return me to this value". > > Patch v3 attached that exposes boot_val and reset_val. The docs for the > latter link to the RESET command page for details. Applied with some smaller changes and minor stylistic fixes. You don't need to copy a text string into buffer and then pstrdup() buffer later - you can just pstrdup() the text string directly. And you forgot one of the places in rules.out :-P Thanks! //Magnus
On Oct 5, 2008, at 8:50 PM, Greg Smith wrote: > Patch v3 attached that exposes boot_val and reset_val. The docs > for the latter link to the RESET command page for details. <nitpick>Is it really that important that we save 2 characters on each field name?</nitpick> -- Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828