Here is some general description of server configuration. Though some of hawq guc is not following that.
DEFUNCT GUC: should not be in doc; should not show in hawq config DEPRECATED GUC: should be in doc and mention that they are deprecated; should show in hawq config DEVELOPER GUC: should not in doc; should not show in hawq config. More details can be found in https://www.postgresql.org/docs/9.5/static/runtime-config-developer.html PRESET GUC: should be in doc as read only; should show in hawq config. More details can be found in https://www.postgresql.org/docs/9.5/static/runtime-config-preset.html Best regards, Ruilong Huo On Fri, Jan 20, 2017 at 1:28 AM, Lisa Owen <[email protected]> wrote: > hi hawq developers, > > i have been looking at src/backend/utils/misc/guc.c to try to get a better > understanding of hawq server configuration parameters (GUCs) and how they > are exposed to end users and developers. i have initially focused on GUCs > with config groups labeled "DEVELOPER_OPTIONS", "DEFUNCT_OPTIONS", > "DEPRECATED_OPTIONS", and "PRESET_OPTIONS". > > i have some general questions regarding these GUC config groups: > 1. which GUCs and their values should be displayed/changeable via "hawq > config" command? > 2. which of the GUCs are updatable, which are read-only? > 3. which of the GUCs should be documented to the end user, and if/how > to "flag them"? > > DEVELOPER_OPTIONS - it appears we expose some developer GUCs to the > end-user. what does it mean for a GUC to be a developer option? (when) > should developer options be displayed in "hawq config -l" output? (when) > should developer GUCs be discussed in the docs? it seems we are somewhat > inconsistent in these areas. many, but not all, of the GUCS labeled as > "DEVELOPER_OPTIONS" are also identified as "GUC_NO_SHOW_ALL", which > generally excludes them from "hawq_config -l" output. the documentation > currently describes a few of the developer GUCs. if we are describing > developer GUCs in end-user documentation, should we be flagging them as > such? > > DEFUNCT_OPTIONS - the GUCs labeled "DEFUNCT_OPTIONS" are pretty > straightforward from an external perspective - none of them are currently > documented, and none show up in "hawq config -l" output. > > DEPRECATED_OPTIONS - GUCs that are part of the "DEPRECATED_OPTIONS" config > group are functioning, but not recommended for use. some are documented, > some are not. should we be explicitly identifying deprecated GUCs as such > in the documentation? should we even be documenting them at all? should > the values of deprecated GUCs show up in "hawq config -l" output? > > PRESET_OPTIONS - some of the GUCS labeled with "PRESET_OPTIONS" are > identified as read-only in the documentation. i used hawq config to change > one of them, "hawq config -c block_size -v 32768", and the operation > apparently worked (i.e. no error returned). so, what does it mean for a > GUC to be preset? read-only? are they all read-only? some appear to be > recognized by "hawq config -c" command, while others are not. > > i've pulled together a spreadsheet identifying the "DEVELOPER_OPTIONS", > "DEFUNCT_OPTIONS", "DEPRECATED_OPTIONS", and "PRESET_OPTIONS" GUCs and > whether or not: > - the GUC is documented in the current HAWQ docs > - the GUC and associated value show up in "hawq config -l" output > (when run by superuser) > and other notes. > > thanks for any clarity you can provide on which of these GUCs we should be > exposing to the end user. > > > -lisa > > >
