Re: [HACKERS] Add default_val to pg_settings
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add default_val to pg_settings
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. nitpickIs it really that important that we save 2 characters on each field name?/nitpick -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Add default_val to pg_settings
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 | 2
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 [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MDIndex: doc/src/sgml/catalogs.sgml
===
RCS file: /home/gsmith/cvsrepo/pgsql/doc/src/sgml/catalogs.sgml,v
retrieving revision 2.174
diff -c -r2.174 catalogs.sgml
*** doc/src/sgml/catalogs.sgml 15 Sep 2008 18:43:41 - 2.174
--- doc/src/sgml/catalogs.sgml 6 Oct 2008 01:17:19 -
***
*** 6422,6427
--- 6422,6439
values)/entry
/row
row
+ entrystructfieldboot_val/structfield/entry
+ entrytypetext/type/entry
+ entryParameter value assumed at server startup if the parameter is
+ not otherwise set/entry
+ /row
+ row
+ entrystructfieldreset_val/structfield/entry
+ entrytypetext/type/entry
+ entryDefault run-time session value for the parameter that it will
+ revert to if commandRESET/command/entry
+ /row
+ row
entrystructfieldsourcefile/structfield/entry
entrytypetext/type/entry
entryInput file the current value was set from (NULL for values set in
Index: src/backend/utils/misc/guc.c
===
RCS file: /home/gsmith/cvsrepo/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.472
diff -c -r1.472 guc.c
*** src/backend/utils/misc/guc.c10 Sep 2008 19:16:22 - 1.472
--- src/backend/utils/misc/guc.c6 Oct 2008 01:20:47 -
***
*** 6087,6092
--- 6087,6094
{
case PGC_BOOL:
{
+ struct config_bool *lconf = (struct config_bool
*) conf;
+
/* min_val */
values[9] = NULL;
***
*** 6095,6100
--- 6097,6110
/* enumvals */
values[11] = NULL;
+
+ /* boot_val */
+ snprintf(buffer, sizeof(buffer), %s,
lconf-boot_val ? on : off);
+ values[12] = pstrdup(buffer);
+
+ /* reset_val */
+ snprintf(buffer, sizeof(buffer), %s,
lconf-reset_val ? on : off);
+ values[13] = pstrdup(buffer);
}
break;
***
*** 6112,6117
--- 6122,6135
/* enumvals */
values[11] = NULL;
+
+ /* boot_val */
+ snprintf(buffer, sizeof(buffer), %d,
lconf-boot_val);
+ values[12] = pstrdup(buffer);
+
+ /* reset_val */
+ snprintf(buffer, sizeof(buffer), %d,
lconf-reset_val);
+ values[13] = pstrdup(buffer);
}
break;
***
*** 6129,6139
--- 6147,6167
/* enumvals */
values[11] = NULL;
+
+ /* boot_val */
+ snprintf(buffer,
Re: [HACKERS] Add default_val to pg_settings
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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add default_val to pg_settings
Simon Riggs [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add default_val to pg_settings
Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add default_val to pg_settings
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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add default_val to pg_settings
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add default_val to pg_settings
Magnus Hagander [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add default_val to pg_settings
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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add default_val to pg_settings
On Thu, 2008-09-25 at 09:15 -0400, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] 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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add default_val to pg_settings
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 [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
