From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: knowing detail of config files via SQL |
Date: | 2015-04-24 18:40:58 |
Message-ID: | 553A8E3A.6020206@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/4/15 9:21 AM, Sawada Masahiko wrote:
> I added documentation changes to patch is attached.
> Also I tried to use memory context for allocation of guc_file_variable
> in TopMemoryContext,
> but it was failed access after received SIGHUP.
Below is my review of the v5 patch:
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
+ <sect1 id="view-pg-file-settings">
+ <title><structname>pg_file_settings</structname></title>
+
+ <indexterm zone="view-pg-file-settings">
+ <primary>pg_file_settings</primary>
+ </indexterm>
+
+ <para>
+ The view <structname>pg_file_settings</structname> provides confirm
parameters via SQL,
+ which is written in configuration file. This view can be update by
reloading configration file.
+ </para>
Perhaps something like:
<para>
The view <structname>pg_file_settings</structname> provides access to
run-time parameters
that are defined in configuration files via SQL. In contrast to
<structname>pg_settings</structname> a row is provided for each
occurrence
of the parameter in a configuration file. This is helpful for
discovering why one value
may have been used in preference to another when the parameters were
loaded.
</para>
+ <table>
+ <title><structname>pg_file_settings</> Columns</title>
+
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Name</entry>
+ <entry>Type</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><structfield>sourcefile</structfield></entry>
+ <entry><structfield>text</structfield></entry>
+ <entry>A path of configration file</entry>
From pg_settings:
<entry>Configuration file the current value was set in (null for
values set from sources other than configuration files, or when
examined by a non-superuser);
helpful when using <literal>include</> directives in configuration
files</entry>
+ </row>
+ <row>
+ <entry><structfield>sourceline</structfield></entry>
+ <entry><structfield>integer</structfield></entry>
+ <entry>The line number in configuration file</entry>
From pg_settings:
<entry>Line number within the configuration file the current value was
set at (null for values set from sources other than configuration
files,
or when examined by a non-superuser)
</entry>
+ </row>
+ <row>
+ <entry><structfield>name</structfield></entry>
+ <entry><structfield>text</structfield></entry>
+ <entry>Parameter name in configuration file</entry>
From pg_settings:
<entry>Run-time configuration parameter name</entry>
+ </row>
+ <row>
+ <entry><structfield>setting</structfield></entry>
+ <entry><structfield>text</structfield></entry>
+ <entry>Value of the parameter in configuration file</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+</sect1>
diff --git a/src/backend/utils/misc/guc-file.l
b/src/backend/utils/misc/guc-file.l
@@ -342,6 +345,42 @@ ProcessConfigFile(GucContext context)
+ guc_array = guc_file_variables;
+ for (item = head; item; item = item->next, guc_array++)
+ {
+ free(guc_array->name);
+ free(guc_array->value);
+ free(guc_array->filename);
There's an issue freeing these when calling pg_reload_conf():
postgres=# alter system set max_connections = 100;
ALTER SYSTEM
postgres=# select * from pg_reload_conf();
LOG: received SIGHUP, reloading configuration files
pg_reload_conf
----------------
t
(1 row)
postgres=# postgres(25078,0x7fff747b2300) malloc: *** error for object
0x424d380044: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Of course a config reload can't change max_connections, but I wouldn't
expect it to crash, either.
+ guc_array->sourceline = -1;
I can't see the need for this since it is reassigned further down.
--
Up-thread David J had recommended an ordering column (or seqno) that
would provide the order in which the settings were loaded. I think this
would give valuable information that can't be gleaned from the line
numbers alone.
Personally I think it would be fine to start from 1 and increment for
each setting found, rather than rank within a setting. If the user
wants per setting ranking that's what SQL is for. So the output would
look something like:
sourcefile | sourceline | seqno | name | setting
--------------------------+------------+-------+-----------------+-----------
/db/postgresql.conf | 64 | 1 | max_connections | 100
/db/postgresql.conf | 116 | 2 | shared_buffers | 128MB
/db/postgresql.conf | 446 | 3 | log_timezone |
US/Eastern
/db/postgresql.auto.conf | 3 | 4 | max_connections | 200
--
- David Steele
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-04-24 19:04:03 | Re: Feedback on getting rid of VACUUM FULL |
Previous Message | Peter Geoghegan | 2015-04-24 18:26:15 | Re: Moving ExecInsertIndexTuples and friends to new file |