rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/include/utils/guc.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

443 lines
17 KiB
C
Raw Normal View History

In the continuing saga of FE/BE protocol revisions, add reporting of initial values and runtime changes in selected parameters. This gets rid of the need for an initial 'select pg_client_encoding()' query in libpq, bringing us back to one message transmitted in each direction for a standard connection startup. To allow server version to be sent using the same GUC mechanism that handles other parameters, invent the concept of a never-settable GUC parameter: you can 'show server_version' but it's not settable by any GUC input source. Create 'lc_collate' and 'lc_ctype' never-settable parameters so that people can find out these settings without need for pg_controldata. (These side ideas were all discussed some time ago in pgsql-hackers, but not yet implemented.)
2003-04-25 21:45:10 +02:00
/*--------------------------------------------------------------------
The heralded `Grand Unified Configuration scheme' (GUC) That means you can now set your options in either or all of $PGDATA/configuration, some postmaster option (--enable-fsync=off), or set a SET command. The list of options is in backend/utils/misc/guc.c, documentation will be written post haste. pg_options is gone, so is that pq_geqo config file. Also removed were backend -K, -Q, and -T options (no longer applicable, although -d0 does the same as -Q). Added to configure an --enable-syslog option. changed all callers from TPRINTF to elog(DEBUG)
2000-05-31 02:28:42 +02:00
* guc.h
*
Split up guc.c for better build speed and ease of maintenance. guc.c has grown to be one of our largest .c files, making it a bottleneck for compilation. It's also acquired a bunch of knowledge that'd be better kept elsewhere, because of our not very good habit of putting variable-specific check hooks here. Hence, split it up along these lines: * guc.c itself retains just the core GUC housekeeping mechanisms. * New file guc_funcs.c contains the SET/SHOW interfaces and some SQL-accessible functions for GUC manipulation. * New file guc_tables.c contains the data arrays that define the built-in GUC variables, along with some already-exported constant tables. * GUC check/assign/show hook functions are moved to the variable's home module, whenever that's clearly identifiable. A few hard- to-classify hooks ended up in commands/variable.c, which was already a home for miscellaneous GUC hook functions. To avoid cluttering a lot more header files with #include "guc.h", I also invented a new header file utils/guc_hooks.h and put all the GUC hook functions' declarations there, regardless of their originating module. That allowed removal of #include "guc.h" from some existing headers. The fallout from that (hopefully all caught here) demonstrates clearly why such inclusions are best minimized: there are a lot of files that, for example, were getting array.h at two or more levels of remove, despite not having any connection at all to GUCs in themselves. There is some very minor code beautification here, such as renaming a couple of inconsistently-named hook functions and improving some comments. But mostly this just moves code from point A to point B and deals with the ensuing needs for #include adjustments and exporting a few functions that previously weren't exported. Patch by me, per a suggestion from Andres Freund; thanks also to Michael Paquier for the idea to invent guc_funcs.c. Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
* External declarations pertaining to Grand Unified Configuration.
The heralded `Grand Unified Configuration scheme' (GUC) That means you can now set your options in either or all of $PGDATA/configuration, some postmaster option (--enable-fsync=off), or set a SET command. The list of options is in backend/utils/misc/guc.c, documentation will be written post haste. pg_options is gone, so is that pq_geqo config file. Also removed were backend -K, -Q, and -T options (no longer applicable, although -d0 does the same as -Q). Added to configure an --enable-syslog option. changed all callers from TPRINTF to elog(DEBUG)
2000-05-31 02:28:42 +02:00
*
Update copyright for 2023 Backpatch-through: 11
2023-01-02 21:00:37 +01:00
* Copyright (c) 2000-2023, PostgreSQL Global Development Group
In the continuing saga of FE/BE protocol revisions, add reporting of initial values and runtime changes in selected parameters. This gets rid of the need for an initial 'select pg_client_encoding()' query in libpq, bringing us back to one message transmitted in each direction for a standard connection startup. To allow server version to be sent using the same GUC mechanism that handles other parameters, invent the concept of a never-settable GUC parameter: you can 'show server_version' but it's not settable by any GUC input source. Create 'lc_collate' and 'lc_ctype' never-settable parameters so that people can find out these settings without need for pg_controldata. (These side ideas were all discussed some time ago in pgsql-hackers, but not yet implemented.)
2003-04-25 21:45:10 +02:00
* Written by Peter Eisentraut <peter_e@gmx.net>.
*
Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
* src/include/utils/guc.h
In the continuing saga of FE/BE protocol revisions, add reporting of initial values and runtime changes in selected parameters. This gets rid of the need for an initial 'select pg_client_encoding()' query in libpq, bringing us back to one message transmitted in each direction for a standard connection startup. To allow server version to be sent using the same GUC mechanism that handles other parameters, invent the concept of a never-settable GUC parameter: you can 'show server_version' but it's not settable by any GUC input source. Create 'lc_collate' and 'lc_ctype' never-settable parameters so that people can find out these settings without need for pg_controldata. (These side ideas were all discussed some time ago in pgsql-hackers, but not yet implemented.)
2003-04-25 21:45:10 +02:00
*--------------------------------------------------------------------
The heralded `Grand Unified Configuration scheme' (GUC) That means you can now set your options in either or all of $PGDATA/configuration, some postmaster option (--enable-fsync=off), or set a SET command. The list of options is in backend/utils/misc/guc.c, documentation will be written post haste. pg_options is gone, so is that pq_geqo config file. Also removed were backend -K, -Q, and -T options (no longer applicable, although -d0 does the same as -Q). Added to configure an --enable-syslog option. changed all callers from TPRINTF to elog(DEBUG)
2000-05-31 02:28:42 +02:00
*/
#ifndef GUC_H
#define GUC_H
Support SET FROM CURRENT in CREATE/ALTER FUNCTION, ALTER DATABASE, ALTER ROLE. (Actually, it works as a plain statement too, but I didn't document that because it seems a bit useless.) Unify VariableResetStmt with VariableSetStmt, and clean up some ancient cruft in the representation of same.
2007-09-03 20:46:30 +02:00
#include "nodes/parsenodes.h"
Restructure command destination handling so that we pass around DestReceiver pointers instead of just CommandDest values. The DestReceiver is made at the point where the destination is selected, rather than deep inside the executor. This cleans up the original kluge implementation of tstoreReceiver.c, and makes it easy to support retrieving results from utility statements inside portals. Thus, you can now do fun things like Bind and Execute a FETCH or EXPLAIN command, and it'll all work as expected (e.g., you can Describe the portal, or use Execute's count parameter to suspend the output partway through). Implementation involves stuffing the utility command's output into a Tuplestore, which would be kind of annoying for huge output sets, but should be quite acceptable for typical uses of utility commands.
2003-05-06 22:26:28 +02:00
#include "tcop/dest.h"
User and database-specific session defaults for run-time configuration variables. New commands ALTER DATABASE ... SET and ALTER USER ... SET.
2002-03-01 23:45:19 +01:00
#include "utils/array.h"
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
Add GUC and storage parameter to set the maximum size of GIN pending list. Previously the maximum size of GIN pending list was controlled only by work_mem. But the reasonable value of work_mem and the reasonable size of the list are basically not the same, so it was not appropriate to control both of them by only one GUC, i.e., work_mem. This commit separates new GUC, pending_list_cleanup_size, from work_mem to allow users to control only the size of the list. Also this commit adds pending_list_cleanup_size as new storage parameter to allow users to specify the size of the list per index. This is useful, for example, when users want to increase the size of the list only for the GIN index which can be updated heavily, and decrease it otherwise. Reviewed by Etsuro Fujita.
2014-11-11 13:08:21 +01:00
/* upper limit for GUC variables measured in kilobytes of memory */
/* note that various places assume the byte size fits in a "long" variable */
#if SIZEOF_SIZE_T > 4 && SIZEOF_LONG > 4
#define MAX_KILOBYTES INT_MAX
#else
#define MAX_KILOBYTES (INT_MAX / 1024)
#endif
Move PG_AUTOCONF_FILENAME definition Since this is not something that a user should change, pg_config_manual.h was an inappropriate place for it. In initdb.c, remove the use of the macro, because utils/guc.h can't be included by non-backend code. But we hardcode all the other configuration file names there, so this isn't a disaster.
2014-12-04 01:54:01 +01:00
/*
* Automatic configuration file name for ALTER SYSTEM.
* This file will be used to store values of configuration parameters
* set by ALTER SYSTEM command.
*/
#define PG_AUTOCONF_FILENAME "postgresql.auto.conf"
The heralded `Grand Unified Configuration scheme' (GUC) That means you can now set your options in either or all of $PGDATA/configuration, some postmaster option (--enable-fsync=off), or set a SET command. The list of options is in backend/utils/misc/guc.c, documentation will be written post haste. pg_options is gone, so is that pq_geqo config file. Also removed were backend -K, -Q, and -T options (no longer applicable, although -d0 does the same as -Q). Added to configure an --enable-syslog option. changed all callers from TPRINTF to elog(DEBUG)
2000-05-31 02:28:42 +02:00
/*
Second pass over run-time configuration system. Adjust priorities on some option settings. Sort out SIGHUP vs BACKEND -- there is no total ordering here, so make explicit checks. Add comments explaining all of this. Removed permissions check on SHOW command. Add examine_subclass to the game, rename to SQL_inheritance to fit the official data model better. Adjust documentation. Standalone backend needs to reset all options before it starts. To facilitate that, have IsUnderPostmaster be set by the postmaster itself, don't wait for the magic -p switch. Also make sure that all environment variables and argv's survive init_ps_display(). Use strdup where necessary. Have initdb make configuration files (postgresql.conf, pg_hba.conf) mode 0600 -- having configuration files is no fun if you can't edit them.
2000-06-23 00:31:24 +02:00
* Certain options can only be set at certain times. The rules are
* like this:
*
In the continuing saga of FE/BE protocol revisions, add reporting of initial values and runtime changes in selected parameters. This gets rid of the need for an initial 'select pg_client_encoding()' query in libpq, bringing us back to one message transmitted in each direction for a standard connection startup. To allow server version to be sent using the same GUC mechanism that handles other parameters, invent the concept of a never-settable GUC parameter: you can 'show server_version' but it's not settable by any GUC input source. Create 'lc_collate' and 'lc_ctype' never-settable parameters so that people can find out these settings without need for pg_controldata. (These side ideas were all discussed some time ago in pgsql-hackers, but not yet implemented.)
2003-04-25 21:45:10 +02:00
* INTERNAL options cannot be set by the user at all, but only through
* internal processes ("server_version" is an example). These are GUC
* variables only so they can be shown by SHOW, etc.
*
Second pass over run-time configuration system. Adjust priorities on some option settings. Sort out SIGHUP vs BACKEND -- there is no total ordering here, so make explicit checks. Add comments explaining all of this. Removed permissions check on SHOW command. Add examine_subclass to the game, rename to SQL_inheritance to fit the official data model better. Adjust documentation. Standalone backend needs to reset all options before it starts. To facilitate that, have IsUnderPostmaster be set by the postmaster itself, don't wait for the magic -p switch. Also make sure that all environment variables and argv's survive init_ps_display(). Use strdup where necessary. Have initdb make configuration files (postgresql.conf, pg_hba.conf) mode 0600 -- having configuration files is no fun if you can't edit them.
2000-06-23 00:31:24 +02:00
* POSTMASTER options can only be set when the postmaster starts,
* either from the configuration file or the command line.
*
* SIGHUP options can only be set at postmaster startup or by changing
* the configuration file and sending the HUP signal to the postmaster
Back out comment update about sighup, original was accurate.
2006-03-07 04:01:22 +01:00
* or a backend process. (Notice that the signal receipt will not be
* evaluated immediately. The postmaster and the backend check it at a
* certain point in their main loop. It's safer to wait than to read a
* file asynchronously.)
Second pass over run-time configuration system. Adjust priorities on some option settings. Sort out SIGHUP vs BACKEND -- there is no total ordering here, so make explicit checks. Add comments explaining all of this. Removed permissions check on SHOW command. Add examine_subclass to the game, rename to SQL_inheritance to fit the official data model better. Adjust documentation. Standalone backend needs to reset all options before it starts. To facilitate that, have IsUnderPostmaster be set by the postmaster itself, don't wait for the magic -p switch. Also make sure that all environment variables and argv's survive init_ps_display(). Use strdup where necessary. Have initdb make configuration files (postgresql.conf, pg_hba.conf) mode 0600 -- having configuration files is no fun if you can't edit them.
2000-06-23 00:31:24 +02:00
*
Invent PGC_SU_BACKEND and mark log_connections/log_disconnections that way. This new GUC context option allows GUC parameters to have the combined properties of PGC_BACKEND and PGC_SUSET, ie, they don't change after session start and non-superusers can't change them. This is a more appropriate choice for log_connections and log_disconnections than their previous context of PGC_BACKEND, because we don't want non-superusers to be able to affect whether their sessions get logged. Note: the behavior for log_connections is still a bit odd, in that when a superuser attempts to set it from PGOPTIONS, the setting takes effect but it's too late to enable or suppress connection startup logging. It's debatable whether that's worth fixing, and in any case there is a reasonable argument for PGC_SU_BACKEND to exist. In passing, re-pgindent the files touched by this commit. Fujii Masao, reviewed by Joe Conway and Amit Kapila
2014-09-14 03:01:49 +02:00
* BACKEND and SU_BACKEND options can only be set at postmaster startup,
* from the configuration file, or by client request in the connection
* startup packet (e.g., from libpq's PGOPTIONS variable). SU_BACKEND
* options can be set from the startup packet only when the user is a
* superuser. Furthermore, an already-started backend will ignore changes
* to such an option in the configuration file. The idea is that these
* options are fixed for a given backend once it's started, but they can
* vary across backends.
Second pass over run-time configuration system. Adjust priorities on some option settings. Sort out SIGHUP vs BACKEND -- there is no total ordering here, so make explicit checks. Add comments explaining all of this. Removed permissions check on SHOW command. Add examine_subclass to the game, rename to SQL_inheritance to fit the official data model better. Adjust documentation. Standalone backend needs to reset all options before it starts. To facilitate that, have IsUnderPostmaster be set by the postmaster itself, don't wait for the magic -p switch. Also make sure that all environment variables and argv's survive init_ps_display(). Use strdup where necessary. Have initdb make configuration files (postgresql.conf, pg_hba.conf) mode 0600 -- having configuration files is no fun if you can't edit them.
2000-06-23 00:31:24 +02:00
*
* SUSET options can be set at postmaster startup, with the SIGHUP
Invent PGC_SU_BACKEND and mark log_connections/log_disconnections that way. This new GUC context option allows GUC parameters to have the combined properties of PGC_BACKEND and PGC_SUSET, ie, they don't change after session start and non-superusers can't change them. This is a more appropriate choice for log_connections and log_disconnections than their previous context of PGC_BACKEND, because we don't want non-superusers to be able to affect whether their sessions get logged. Note: the behavior for log_connections is still a bit odd, in that when a superuser attempts to set it from PGOPTIONS, the setting takes effect but it's too late to enable or suppress connection startup logging. It's debatable whether that's worth fixing, and in any case there is a reasonable argument for PGC_SU_BACKEND to exist. In passing, re-pgindent the files touched by this commit. Fujii Masao, reviewed by Joe Conway and Amit Kapila
2014-09-14 03:01:49 +02:00
* mechanism, or from the startup packet or SQL if you're a superuser.
Second pass over run-time configuration system. Adjust priorities on some option settings. Sort out SIGHUP vs BACKEND -- there is no total ordering here, so make explicit checks. Add comments explaining all of this. Removed permissions check on SHOW command. Add examine_subclass to the game, rename to SQL_inheritance to fit the official data model better. Adjust documentation. Standalone backend needs to reset all options before it starts. To facilitate that, have IsUnderPostmaster be set by the postmaster itself, don't wait for the magic -p switch. Also make sure that all environment variables and argv's survive init_ps_display(). Use strdup where necessary. Have initdb make configuration files (postgresql.conf, pg_hba.conf) mode 0600 -- having configuration files is no fun if you can't edit them.
2000-06-23 00:31:24 +02:00
*
* USERSET options can be set by anyone any time.
The heralded `Grand Unified Configuration scheme' (GUC) That means you can now set your options in either or all of $PGDATA/configuration, some postmaster option (--enable-fsync=off), or set a SET command. The list of options is in backend/utils/misc/guc.c, documentation will be written post haste. pg_options is gone, so is that pq_geqo config file. Also removed were backend -K, -Q, and -T options (no longer applicable, although -d0 does the same as -Q). Added to configure an --enable-syslog option. changed all callers from TPRINTF to elog(DEBUG)
2000-05-31 02:28:42 +02:00
*/
typedef enum
{
Code review for recent GUC changes --- try to make it less obvious that these things were added at different times by different people ;-). Includes Aizaz Ahmed's patch to remove duplicate array in help_config.c.
2003-07-28 21:31:32 +02:00
PGC_INTERNAL,
PGC_POSTMASTER,
PGC_SIGHUP,
Invent PGC_SU_BACKEND and mark log_connections/log_disconnections that way. This new GUC context option allows GUC parameters to have the combined properties of PGC_BACKEND and PGC_SUSET, ie, they don't change after session start and non-superusers can't change them. This is a more appropriate choice for log_connections and log_disconnections than their previous context of PGC_BACKEND, because we don't want non-superusers to be able to affect whether their sessions get logged. Note: the behavior for log_connections is still a bit odd, in that when a superuser attempts to set it from PGOPTIONS, the setting takes effect but it's too late to enable or suppress connection startup logging. It's debatable whether that's worth fixing, and in any case there is a reasonable argument for PGC_SU_BACKEND to exist. In passing, re-pgindent the files touched by this commit. Fujii Masao, reviewed by Joe Conway and Amit Kapila
2014-09-14 03:01:49 +02:00
PGC_SU_BACKEND,
Code review for recent GUC changes --- try to make it less obvious that these things were added at different times by different people ;-). Includes Aizaz Ahmed's patch to remove duplicate array in help_config.c.
2003-07-28 21:31:32 +02:00
PGC_BACKEND,
PGC_SUSET,
PGC_USERSET
The heralded `Grand Unified Configuration scheme' (GUC) That means you can now set your options in either or all of $PGDATA/configuration, some postmaster option (--enable-fsync=off), or set a SET command. The list of options is in backend/utils/misc/guc.c, documentation will be written post haste. pg_options is gone, so is that pq_geqo config file. Also removed were backend -K, -Q, and -T options (no longer applicable, although -d0 does the same as -Q). Added to configure an --enable-syslog option. changed all callers from TPRINTF to elog(DEBUG)
2000-05-31 02:28:42 +02:00
} GucContext;
Save source of GUC settings, allowing different sources to be processed in any order without affecting results.
2002-02-23 02:31:37 +01:00
/*
* The following type records the source of the current setting. A
* new setting can only take effect if the previous setting had the
* same or lower level. (E.g, changing the config file doesn't
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
* override the postmaster command line.) Tracking the source allows us
* to process sources in any convenient order without affecting results.
* Sources <= PGC_S_OVERRIDE will set the default used by RESET, as well
Be more careful about GucSource for internally-driven GUC settings. The original advice for hard-wired SetConfigOption calls was to use PGC_S_OVERRIDE, particularly for PGC_INTERNAL GUCs. However, that's really overkill for PGC_INTERNAL GUCs, since there is no possibility that we need to override a user-provided setting. Instead use PGC_S_DYNAMIC_DEFAULT in most places, so that the value will appear with source = 'default' in pg_settings and thereby not be shown by psql's new \dconfig command. The one exception is that when changing in_hot_standby in a hot-standby session, we still use PGC_S_OVERRIDE, because people felt that seeing that in \dconfig would be a good thing. Similarly use PGC_S_DYNAMIC_DEFAULT for the auto-tune value of wal_buffers (if possible, that is if wal_buffers wasn't explicitly set to -1), and for the typical 2MB value of max_stack_depth. In combination these changes remove four not-very-interesting entries from the typical output of \dconfig, all of which people fingered as "why is that showing up?" in the discussion thread. Discussion: https://postgr.es/m/3118455.1649267333@sss.pgh.pa.us
2022-06-08 19:26:18 +02:00
* as the current value.
> Joe Conway <mail@joeconway.com> writes: >>ISTM that "source" is worth knowing. > > Hm, possibly. Any other opinions? This version has the seven fields I proposed, including "source". Here's an example that shows why I think it's valuable: regression=# \x Expanded display is on. regression=# select * from pg_settings where name = 'enable_seqscan'; -[ RECORD 1 ]----------- name | enable_seqscan setting | on context | user vartype | bool source | default min_val | max_val | regression=# update pg_settings set setting = 'off' where name = 'enable_seqscan'; -[ RECORD 1 ]--- set_config | off regression=# select * from pg_settings where name = 'enable_seqscan'; -[ RECORD 1 ]----------- name | enable_seqscan setting | off context | user vartype | bool source | session min_val | max_val | regression=# alter user postgres set enable_seqscan to 'off'; ALTER USER (log out and then back in again) regression=# \x Expanded display is on. regression=# select * from pg_settings where name = 'enable_seqscan'; -[ RECORD 1 ]----------- name | enable_seqscan setting | off context | user vartype | bool source | user min_val | max_val | In the first case, enable_seqscan is set to its default value. After setting it to off, it is obvious that the value has been changed for the session only. In the third case, you can see that the value has been set specifically for the user. Joe Conway
2003-07-27 06:35:54 +02:00
*
Remove GUC USERLIMIT variable category, making the affected variables plain SUSET instead. Also delay processing of options received in client connection request until after we know if the user is a superuser, so that SUSET values can be set that way by legitimate superusers. Per recent discussion.
2004-11-14 20:35:35 +01:00
* PGC_S_INTERACTIVE isn't actually a source value, but is the
Repair problem identified by Olivier Prenant: ALTER DATABASE SET search_path should not be too eager to reject paths involving unknown schemas, since it can't really tell whether the schemas exist in the target database. (Also, when reading pg_dumpall output, it could be that the schemas don't exist yet, but eventually will.) ALTER USER SET has a similar issue. So, reduce the normal ERROR to a NOTICE when checking search_path values for these commands. Supporting this requires changing the API for GUC assign_hook functions, which causes the patch to touch a lot of places, but the changes are conceptually trivial.
2004-01-19 20:04:40 +01:00
* dividing line between "interactive" and "non-interactive" sources for
* error reporting purposes.
*
Fix typos and grammar in documentation and code comments Comment fixes are applied on HEAD, and documentation improvements are applied on back-branches where needed. Author: Justin Pryzby Discussion: https://postgr.es/m/20210408164008.GJ6592@telsasoft.com Backpatch-through: 9.6
2021-04-09 06:53:07 +02:00
* PGC_S_TEST is used when testing values to be used later. For example,
* ALTER DATABASE/ROLE tests proposed per-database or per-user defaults this
* way, and CREATE FUNCTION tests proposed function SET clauses this way.
* This is an interactive case, but it needs its own source value because
* some assign hooks need to make different validity checks in this case.
* In particular, references to nonexistent database objects generally
Update comments concerning PGC_S_TEST. This GUC context value was once only used by ALTER DATABASE SET and ALTER USER SET. That's not true anymore, though, so rewrite the comments to be a bit more general. Patch in HEAD only, since this is just an internal documentation issue.
2013-09-04 00:56:22 +02:00
* shouldn't throw hard errors in this case, at most NOTICEs, since the
* objects might exist by the time the setting is used for real.
Add new PGC_S_DATABASE_USER enum value to several places missed by my patch last week. Per note and patch from Jeff Davis.
2009-10-13 16:18:40 +02:00
*
Be more careful about GucSource for internally-driven GUC settings. The original advice for hard-wired SetConfigOption calls was to use PGC_S_OVERRIDE, particularly for PGC_INTERNAL GUCs. However, that's really overkill for PGC_INTERNAL GUCs, since there is no possibility that we need to override a user-provided setting. Instead use PGC_S_DYNAMIC_DEFAULT in most places, so that the value will appear with source = 'default' in pg_settings and thereby not be shown by psql's new \dconfig command. The one exception is that when changing in_hot_standby in a hot-standby session, we still use PGC_S_OVERRIDE, because people felt that seeing that in \dconfig would be a good thing. Similarly use PGC_S_DYNAMIC_DEFAULT for the auto-tune value of wal_buffers (if possible, that is if wal_buffers wasn't explicitly set to -1), and for the typical 2MB value of max_stack_depth. In combination these changes remove four not-very-interesting entries from the typical output of \dconfig, all of which people fingered as "why is that showing up?" in the discussion thread. Discussion: https://postgr.es/m/3118455.1649267333@sss.pgh.pa.us
2022-06-08 19:26:18 +02:00
* When setting the value of a non-compile-time-constant PGC_INTERNAL option,
* source == PGC_S_DYNAMIC_DEFAULT should typically be used so that the value
* will show as "default" in pg_settings. If there is a specific reason not
* to want that, use source == PGC_S_OVERRIDE.
*
Add new PGC_S_DATABASE_USER enum value to several places missed by my patch last week. Per note and patch from Jeff Davis.
2009-10-13 16:18:40 +02:00
* NB: see GucSource_Names in guc.c if you change this.
Save source of GUC settings, allowing different sources to be processed in any order without affecting results.
2002-02-23 02:31:37 +01:00
*/
typedef enum
{
Split PGC_S_DEFAULT into two values, for true boot_val vs computed default. Failure to distinguish these cases is the real cause behind the recent reports of Windows builds crashing on 'infinity'::timestamp, which was directly due to failure to establish a value of timezone_abbreviations in postmaster child processes. The postmaster had the desired value, but write_one_nondefault_variable() didn't transmit it to backends. To fix that, invent a new value PGC_S_DYNAMIC_DEFAULT, and be sure to use that or PGC_S_ENV_VAR (as appropriate) for "default" settings that are computed during initialization. (We need both because there's at least one variable that could receive a value from either source.) This commit also fixes ProcessConfigFile's failure to restore the correct default value for certain GUC variables if they are set in postgresql.conf and then removed/commented out of the file. We have to recompute and reinstall the value for any GUC variable that could have received a value from PGC_S_DYNAMIC_DEFAULT or PGC_S_ENV_VAR sources, and there were a number of oversights. (That whole thing is a crock that needs to be redesigned, but not today.) However, I intentionally didn't make it work "exactly right" for the cases of timezone and log_timezone. The exactly right behavior would involve running select_default_timezone, which we'd have to do independently in each postgres process, causing the whole database to become entirely unresponsive for as much as several seconds. That didn't seem like a good idea, especially since the variable's removal from postgresql.conf might be just an accidental edit. Instead the behavior is to adopt the previously active setting as if it were default. Note that this patch creates an ABI break for extensions that use any of the PGC_S_XXX constants; they'll need to be recompiled.
2011-05-12 01:57:38 +02:00
PGC_S_DEFAULT, /* hard-wired default ("boot_val") */
PGC_S_DYNAMIC_DEFAULT, /* default computed during initialization */
Code review for recent GUC changes --- try to make it less obvious that these things were added at different times by different people ;-). Includes Aizaz Ahmed's patch to remove duplicate array in help_config.c.
2003-07-28 21:31:32 +02:00
PGC_S_ENV_VAR, /* postmaster environment variable */
PGC_S_FILE, /* postgresql.conf */
PGC_S_ARGV, /* postmaster command line */
Add ALTER ROLE ALL SET command This generalizes the existing ALTER ROLE ... SET and ALTER DATABASE ... SET functionality to allow creating settings that apply to all users in all databases. reviewed by Pavel Stehule
2013-02-18 05:45:36 +01:00
PGC_S_GLOBAL, /* global in-database setting */
Code review for recent GUC changes --- try to make it less obvious that these things were added at different times by different people ;-). Includes Aizaz Ahmed's patch to remove duplicate array in help_config.c.
2003-07-28 21:31:32 +02:00
PGC_S_DATABASE, /* per-database setting */
PGC_S_USER, /* per-user setting */
Make it possibly to specify GUC params per user and per database. Create a new catalog pg_db_role_setting where they are now stored, and better encapsulate the code that deals with settings into its realm. The old datconfig and rolconfig columns are removed. psql has gained a \drds command to display the settings. Backwards compatibility warning: while the backwards-compatible system views still have the config columns, they no longer completely represent the configuration for a user or database. Catalog version bumped.
2009-10-08 00:14:26 +02:00
PGC_S_DATABASE_USER, /* per-user-and-database setting */
Code review for recent GUC changes --- try to make it less obvious that these things were added at different times by different people ;-). Includes Aizaz Ahmed's patch to remove duplicate array in help_config.c.
2003-07-28 21:31:32 +02:00
PGC_S_CLIENT, /* from client connection request */
PGC_S_OVERRIDE, /* special case to forcibly set default */
Repair problem identified by Olivier Prenant: ALTER DATABASE SET search_path should not be too eager to reject paths involving unknown schemas, since it can't really tell whether the schemas exist in the target database. (Also, when reading pg_dumpall output, it could be that the schemas don't exist yet, but eventually will.) ALTER USER SET has a similar issue. So, reduce the normal ERROR to a NOTICE when checking search_path values for these commands. Supporting this requires changing the API for GUC assign_hook functions, which causes the patch to touch a lot of places, but the changes are conceptually trivial.
2004-01-19 20:04:40 +01:00
PGC_S_INTERACTIVE, /* dividing line for error reporting */
PGC_S_TEST, /* test per-database or per-user setting */
Code review for recent GUC changes --- try to make it less obvious that these things were added at different times by different people ;-). Includes Aizaz Ahmed's patch to remove duplicate array in help_config.c.
2003-07-28 21:31:32 +02:00
PGC_S_SESSION /* SET command */
Save source of GUC settings, allowing different sources to be processed in any order without affecting results.
2002-02-23 02:31:37 +01:00
} GucSource;
The heralded `Grand Unified Configuration scheme' (GUC) That means you can now set your options in either or all of $PGDATA/configuration, some postmaster option (--enable-fsync=off), or set a SET command. The list of options is in backend/utils/misc/guc.c, documentation will be written post haste. pg_options is gone, so is that pq_geqo config file. Also removed were backend -K, -Q, and -T options (no longer applicable, although -d0 does the same as -Q). Added to configure an --enable-syslog option. changed all callers from TPRINTF to elog(DEBUG)
2000-05-31 02:28:42 +02:00
Use GUC lexer for recovery.conf parsing. This eliminates some crufty, special-purpose code and, as a non-trivial side benefit, allows recovery.conf parameters to be unquoted. Dimitri Fontaine, with review and cleanup by Alvaro Herrera, Itagaki Takahiro, and me.
2010-12-03 14:44:15 +01:00
/*
Improve design and implementation of pg_file_settings view. As first committed, this view reported on the file contents as they were at the last SIGHUP event. That's not as useful as reporting on the current contents, and what's more, it didn't work right on Windows unless the current session had serviced at least one SIGHUP. Therefore, arrange to re-read the files when pg_show_all_settings() is called. This requires only minor refactoring so that we can pass changeVal = false to set_config_option() so that it won't actually apply any changes locally. In addition, add error reporting so that errors that would prevent the configuration files from being loaded, or would prevent individual settings from being applied, are visible directly in the view. This makes the view usable for pre-testing whether edits made in the config files will have the desired effect, before one actually issues a SIGHUP. I also added an "applied" column so that it's easy to identify entries that are superseded by later entries; this was the main use-case for the original design, but it seemed unnecessarily hard to use for that. Also fix a 9.4.1 regression that allowed multiple entries for a PGC_POSTMASTER variable to cause bogus complaints in the postmaster log. (The issue here was that commit bf007a27acd7b2fb unintentionally reverted 3e3f65973a3c94a6, which suppressed any duplicate entries within ParseConfigFp. However, since the original coding of the pg_file_settings view depended on such suppression *not* happening, we couldn't have fixed this issue now without first doing something with pg_file_settings. Now we suppress duplicates by marking them "ignored" within ProcessConfigFileInternal, which doesn't hide them in the view.) Lesser changes include: Drive the view directly off the ConfigVariable list, instead of making a basically-equivalent second copy of the data. There's no longer any need to hang onto the data permanently, anyway. Convert show_all_file_settings() to do its work in one call and return a tuplestore; this avoids risks associated with assuming that the GUC state will hold still over the course of query execution. (I think there were probably latent bugs here, though you might need something like a cursor on the view to expose them.) Arrange to run SIGHUP processing in a short-lived memory context, to forestall process-lifespan memory leaks. (There is one known leak in this code, in ProcessConfigDirectory; it seems minor enough to not be worth back-patching a specific fix for.) Remove mistaken assignment to ConfigFileLineno that caused line counting after an include_dir directive to be completely wrong. Add missed failure check in AlterSystemSetConfigFile(). We don't really expect ParseConfigFp() to fail, but that's not an excuse for not checking.
2015-06-29 00:06:14 +02:00
* Parsing the configuration file(s) will return a list of name-value pairs
* with source location info. We also abuse this data structure to carry
* error reports about the config files. An entry reporting an error will
* have errmsg != NULL, and might have NULLs for name, value, and/or filename.
*
* If "ignore" is true, don't attempt to apply the item (it might be an error
* report, or an item we determined to be duplicate). "applied" is set true
* if we successfully applied, or could have applied, the setting.
Use GUC lexer for recovery.conf parsing. This eliminates some crufty, special-purpose code and, as a non-trivial side benefit, allows recovery.conf parameters to be unquoted. Dimitri Fontaine, with review and cleanup by Alvaro Herrera, Itagaki Takahiro, and me.
2010-12-03 14:44:15 +01:00
*/
typedef struct ConfigVariable
{
char *name;
char *value;
Improve design and implementation of pg_file_settings view. As first committed, this view reported on the file contents as they were at the last SIGHUP event. That's not as useful as reporting on the current contents, and what's more, it didn't work right on Windows unless the current session had serviced at least one SIGHUP. Therefore, arrange to re-read the files when pg_show_all_settings() is called. This requires only minor refactoring so that we can pass changeVal = false to set_config_option() so that it won't actually apply any changes locally. In addition, add error reporting so that errors that would prevent the configuration files from being loaded, or would prevent individual settings from being applied, are visible directly in the view. This makes the view usable for pre-testing whether edits made in the config files will have the desired effect, before one actually issues a SIGHUP. I also added an "applied" column so that it's easy to identify entries that are superseded by later entries; this was the main use-case for the original design, but it seemed unnecessarily hard to use for that. Also fix a 9.4.1 regression that allowed multiple entries for a PGC_POSTMASTER variable to cause bogus complaints in the postmaster log. (The issue here was that commit bf007a27acd7b2fb unintentionally reverted 3e3f65973a3c94a6, which suppressed any duplicate entries within ParseConfigFp. However, since the original coding of the pg_file_settings view depended on such suppression *not* happening, we couldn't have fixed this issue now without first doing something with pg_file_settings. Now we suppress duplicates by marking them "ignored" within ProcessConfigFileInternal, which doesn't hide them in the view.) Lesser changes include: Drive the view directly off the ConfigVariable list, instead of making a basically-equivalent second copy of the data. There's no longer any need to hang onto the data permanently, anyway. Convert show_all_file_settings() to do its work in one call and return a tuplestore; this avoids risks associated with assuming that the GUC state will hold still over the course of query execution. (I think there were probably latent bugs here, though you might need something like a cursor on the view to expose them.) Arrange to run SIGHUP processing in a short-lived memory context, to forestall process-lifespan memory leaks. (There is one known leak in this code, in ProcessConfigDirectory; it seems minor enough to not be worth back-patching a specific fix for.) Remove mistaken assignment to ConfigFileLineno that caused line counting after an include_dir directive to be completely wrong. Add missed failure check in AlterSystemSetConfigFile(). We don't really expect ParseConfigFp() to fail, but that's not an excuse for not checking.
2015-06-29 00:06:14 +02:00
char *errmsg;
Use GUC lexer for recovery.conf parsing. This eliminates some crufty, special-purpose code and, as a non-trivial side benefit, allows recovery.conf parameters to be unquoted. Dimitri Fontaine, with review and cleanup by Alvaro Herrera, Itagaki Takahiro, and me.
2010-12-03 14:44:15 +01:00
char *filename;
int sourceline;
Improve design and implementation of pg_file_settings view. As first committed, this view reported on the file contents as they were at the last SIGHUP event. That's not as useful as reporting on the current contents, and what's more, it didn't work right on Windows unless the current session had serviced at least one SIGHUP. Therefore, arrange to re-read the files when pg_show_all_settings() is called. This requires only minor refactoring so that we can pass changeVal = false to set_config_option() so that it won't actually apply any changes locally. In addition, add error reporting so that errors that would prevent the configuration files from being loaded, or would prevent individual settings from being applied, are visible directly in the view. This makes the view usable for pre-testing whether edits made in the config files will have the desired effect, before one actually issues a SIGHUP. I also added an "applied" column so that it's easy to identify entries that are superseded by later entries; this was the main use-case for the original design, but it seemed unnecessarily hard to use for that. Also fix a 9.4.1 regression that allowed multiple entries for a PGC_POSTMASTER variable to cause bogus complaints in the postmaster log. (The issue here was that commit bf007a27acd7b2fb unintentionally reverted 3e3f65973a3c94a6, which suppressed any duplicate entries within ParseConfigFp. However, since the original coding of the pg_file_settings view depended on such suppression *not* happening, we couldn't have fixed this issue now without first doing something with pg_file_settings. Now we suppress duplicates by marking them "ignored" within ProcessConfigFileInternal, which doesn't hide them in the view.) Lesser changes include: Drive the view directly off the ConfigVariable list, instead of making a basically-equivalent second copy of the data. There's no longer any need to hang onto the data permanently, anyway. Convert show_all_file_settings() to do its work in one call and return a tuplestore; this avoids risks associated with assuming that the GUC state will hold still over the course of query execution. (I think there were probably latent bugs here, though you might need something like a cursor on the view to expose them.) Arrange to run SIGHUP processing in a short-lived memory context, to forestall process-lifespan memory leaks. (There is one known leak in this code, in ProcessConfigDirectory; it seems minor enough to not be worth back-patching a specific fix for.) Remove mistaken assignment to ConfigFileLineno that caused line counting after an include_dir directive to be completely wrong. Add missed failure check in AlterSystemSetConfigFile(). We don't really expect ParseConfigFp() to fail, but that's not an excuse for not checking.
2015-06-29 00:06:14 +02:00
bool ignore;
bool applied;
Use GUC lexer for recovery.conf parsing. This eliminates some crufty, special-purpose code and, as a non-trivial side benefit, allows recovery.conf parameters to be unquoted. Dimitri Fontaine, with review and cleanup by Alvaro Herrera, Itagaki Takahiro, and me.
2010-12-03 14:44:15 +01:00
struct ConfigVariable *next;
} ConfigVariable;
Improve design and implementation of pg_file_settings view. As first committed, this view reported on the file contents as they were at the last SIGHUP event. That's not as useful as reporting on the current contents, and what's more, it didn't work right on Windows unless the current session had serviced at least one SIGHUP. Therefore, arrange to re-read the files when pg_show_all_settings() is called. This requires only minor refactoring so that we can pass changeVal = false to set_config_option() so that it won't actually apply any changes locally. In addition, add error reporting so that errors that would prevent the configuration files from being loaded, or would prevent individual settings from being applied, are visible directly in the view. This makes the view usable for pre-testing whether edits made in the config files will have the desired effect, before one actually issues a SIGHUP. I also added an "applied" column so that it's easy to identify entries that are superseded by later entries; this was the main use-case for the original design, but it seemed unnecessarily hard to use for that. Also fix a 9.4.1 regression that allowed multiple entries for a PGC_POSTMASTER variable to cause bogus complaints in the postmaster log. (The issue here was that commit bf007a27acd7b2fb unintentionally reverted 3e3f65973a3c94a6, which suppressed any duplicate entries within ParseConfigFp. However, since the original coding of the pg_file_settings view depended on such suppression *not* happening, we couldn't have fixed this issue now without first doing something with pg_file_settings. Now we suppress duplicates by marking them "ignored" within ProcessConfigFileInternal, which doesn't hide them in the view.) Lesser changes include: Drive the view directly off the ConfigVariable list, instead of making a basically-equivalent second copy of the data. There's no longer any need to hang onto the data permanently, anyway. Convert show_all_file_settings() to do its work in one call and return a tuplestore; this avoids risks associated with assuming that the GUC state will hold still over the course of query execution. (I think there were probably latent bugs here, though you might need something like a cursor on the view to expose them.) Arrange to run SIGHUP processing in a short-lived memory context, to forestall process-lifespan memory leaks. (There is one known leak in this code, in ProcessConfigDirectory; it seems minor enough to not be worth back-patching a specific fix for.) Remove mistaken assignment to ConfigFileLineno that caused line counting after an include_dir directive to be completely wrong. Add missed failure check in AlterSystemSetConfigFile(). We don't really expect ParseConfigFp() to fail, but that's not an excuse for not checking.
2015-06-29 00:06:14 +02:00
extern bool ParseConfigFile(const char *config_file, bool strict,
const char *calling_file, int calling_lineno,
int depth, int elevel,
Use GUC lexer for recovery.conf parsing. This eliminates some crufty, special-purpose code and, as a non-trivial side benefit, allows recovery.conf parameters to be unquoted. Dimitri Fontaine, with review and cleanup by Alvaro Herrera, Itagaki Takahiro, and me.
2010-12-03 14:44:15 +01:00
ConfigVariable **head_p, ConfigVariable **tail_p);
extern bool ParseConfigFp(FILE *fp, const char *config_file,
int depth, int elevel,
ConfigVariable **head_p, ConfigVariable **tail_p);
Add support for include_dir in config file. This allows easily splitting configuration into many files, deployed in a directory. Magnus Hagander, Greg Smith, Selena Deckelmann, reviewed by Noah Misch.
2012-09-24 16:55:53 +02:00
extern bool ParseConfigDirectory(const char *includedir,
Improve design and implementation of pg_file_settings view. As first committed, this view reported on the file contents as they were at the last SIGHUP event. That's not as useful as reporting on the current contents, and what's more, it didn't work right on Windows unless the current session had serviced at least one SIGHUP. Therefore, arrange to re-read the files when pg_show_all_settings() is called. This requires only minor refactoring so that we can pass changeVal = false to set_config_option() so that it won't actually apply any changes locally. In addition, add error reporting so that errors that would prevent the configuration files from being loaded, or would prevent individual settings from being applied, are visible directly in the view. This makes the view usable for pre-testing whether edits made in the config files will have the desired effect, before one actually issues a SIGHUP. I also added an "applied" column so that it's easy to identify entries that are superseded by later entries; this was the main use-case for the original design, but it seemed unnecessarily hard to use for that. Also fix a 9.4.1 regression that allowed multiple entries for a PGC_POSTMASTER variable to cause bogus complaints in the postmaster log. (The issue here was that commit bf007a27acd7b2fb unintentionally reverted 3e3f65973a3c94a6, which suppressed any duplicate entries within ParseConfigFp. However, since the original coding of the pg_file_settings view depended on such suppression *not* happening, we couldn't have fixed this issue now without first doing something with pg_file_settings. Now we suppress duplicates by marking them "ignored" within ProcessConfigFileInternal, which doesn't hide them in the view.) Lesser changes include: Drive the view directly off the ConfigVariable list, instead of making a basically-equivalent second copy of the data. There's no longer any need to hang onto the data permanently, anyway. Convert show_all_file_settings() to do its work in one call and return a tuplestore; this avoids risks associated with assuming that the GUC state will hold still over the course of query execution. (I think there were probably latent bugs here, though you might need something like a cursor on the view to expose them.) Arrange to run SIGHUP processing in a short-lived memory context, to forestall process-lifespan memory leaks. (There is one known leak in this code, in ProcessConfigDirectory; it seems minor enough to not be worth back-patching a specific fix for.) Remove mistaken assignment to ConfigFileLineno that caused line counting after an include_dir directive to be completely wrong. Add missed failure check in AlterSystemSetConfigFile(). We don't really expect ParseConfigFp() to fail, but that's not an excuse for not checking.
2015-06-29 00:06:14 +02:00
const char *calling_file, int calling_lineno,
Add support for include_dir in config file. This allows easily splitting configuration into many files, deployed in a directory. Magnus Hagander, Greg Smith, Selena Deckelmann, reviewed by Noah Misch.
2012-09-24 16:55:53 +02:00
int depth, int elevel,
ConfigVariable **head_p,
ConfigVariable **tail_p);
Use GUC lexer for recovery.conf parsing. This eliminates some crufty, special-purpose code and, as a non-trivial side benefit, allows recovery.conf parameters to be unquoted. Dimitri Fontaine, with review and cleanup by Alvaro Herrera, Itagaki Takahiro, and me.
2010-12-03 14:44:15 +01:00
extern void FreeConfigVariables(ConfigVariable *list);
Make postgres.bki use the same literal-string syntax as postgresql.conf. The BKI file's string quoting conventions were previously quite weird, perhaps as a result of repurposing a function built to scan single-quoted strings to scan double-quoted ones. Change to use the same rules as we use in GUC files, allowing some simplifications in genbki.pl and initdb.c. While at it, completely remove the backend's scanstr() function, which was essentially a duplicate of the string dequoting code in guc-file.l. Instead export that one (under a less generic name than it had) and let bootscanner.l use it. Now we can clarify that scansup.c exists only to support the main lexer. We could alternatively have removed GUC_scanstr, but this way seems better since the previous arrangement could mislead a reader into thinking that scanstr() had something to do with the main lexer's handling of string literals. Maybe it did once, but if so it was a long time ago. This patch does not bump catversion, since the initially-installed catalog contents don't change. Note however that successful initdb after applying this patch will require up-to-date postgres.bki as well as postgres and initdb executables. In passing, remove a bunch of very-long-obsolete #include's in bootparse.y and bootscanner.l. John Naylor Discussion: https://postgr.es/m/CACPNZCtDpd18T0KATTmCggO2GdVC4ow86ypiq5ENff1VnauL8g@mail.gmail.com
2020-10-04 22:09:55 +02:00
extern char *DeescapeQuotedString(const char *s);
Use GUC lexer for recovery.conf parsing. This eliminates some crufty, special-purpose code and, as a non-trivial side benefit, allows recovery.conf parameters to be unquoted. Dimitri Fontaine, with review and cleanup by Alvaro Herrera, Itagaki Takahiro, and me.
2010-12-03 14:44:15 +01:00
Some cleanups of enum-guc code, per comments from Tom.
2008-03-16 17:42:44 +01:00
/*
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
* The possible values of an enum variable are specified by an array of
* name-value pairs. The "hidden" flag means the value is accepted but
* won't be displayed when guc.c is asked for a list of acceptable values.
Some cleanups of enum-guc code, per comments from Tom.
2008-03-16 17:42:44 +01:00
*/
struct config_enum_entry
{
const char *name;
int val;
Add a field to guc enums to allow hiding of values from display while still accepting them as input, used to allow alternate syntax for the same setting. Alex Hunsaker
2008-05-28 11:04:06 +02:00
bool hidden;
Some cleanups of enum-guc code, per comments from Tom.
2008-03-16 17:42:44 +01:00
};
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
/*
* Signatures for per-variable check/assign/show hook functions
*/
typedef bool (*GucBoolCheckHook) (bool *newval, void **extra, GucSource source);
typedef bool (*GucIntCheckHook) (int *newval, void **extra, GucSource source);
typedef bool (*GucRealCheckHook) (double *newval, void **extra, GucSource source);
typedef bool (*GucStringCheckHook) (char **newval, void **extra, GucSource source);
typedef bool (*GucEnumCheckHook) (int *newval, void **extra, GucSource source);
typedef void (*GucBoolAssignHook) (bool newval, void *extra);
typedef void (*GucIntAssignHook) (int newval, void *extra);
typedef void (*GucRealAssignHook) (double newval, void *extra);
typedef void (*GucStringAssignHook) (const char *newval, void *extra);
typedef void (*GucEnumAssignHook) (int newval, void *extra);
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
typedef const char *(*GucShowHook) (void);
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
/*
* Miscellaneous
*/
Arrange for SET LOCAL's effects to persist until the end of the current top transaction, unless rolled back or overridden by a SET clause for the same variable attached to a surrounding function call. Per discussion, these seem the best semantics. Note that this is an INCOMPATIBLE CHANGE: in 8.0 through 8.2, SET LOCAL's effects disappeared at subtransaction commit (leading to behavior that made little sense at the SQL level). I took advantage of the opportunity to rewrite and simplify the GUC variable save/restore logic a little bit. The old idea of a "tentative" value is gone; it was a hangover from before we had a stack. Also, we no longer need a stack entry for every nesting level, but only for those in which a variable's value actually changed.
2007-09-11 02:06:42 +02:00
typedef enum
{
/* Types of set_config_option actions */
GUC_ACTION_SET, /* regular SET command */
GUC_ACTION_LOCAL, /* SET LOCAL command */
Improve and simplify CREATE EXTENSION's management of GUC variables. CREATE EXTENSION needs to transiently set search_path, as well as client_min_messages and log_min_messages. We were doing this by the expedient of saving the current string value of each variable, doing a SET LOCAL, and then doing another SET LOCAL with the previous value at the end of the command. This is a bit expensive though, and it also fails badly if there is anything funny about the existing search_path value, as seen in a recent report from Roger Niederland. Fortunately, there's a much better way, which is to piggyback on the GUC infrastructure previously developed for functions with SET options. We just open a new GUC nesting level, do our assignments with GUC_ACTION_SAVE, and then close the nesting level when done. This automatically restores the prior settings without a re-parsing pass, so (in principle anyway) there can't be an error. And guc.c still takes care of cleanup in event of an error abort. The CREATE EXTENSION code for this was modeled on some much older code in ri_triggers.c, which I also changed to use the better method, even though there wasn't really much risk of failure there. Also improve the comments in guc.c to reflect this additional usage.
2011-10-06 02:44:16 +02:00
GUC_ACTION_SAVE /* function SET option, or temp assignment */
Arrange for SET LOCAL's effects to persist until the end of the current top transaction, unless rolled back or overridden by a SET clause for the same variable attached to a surrounding function call. Per discussion, these seem the best semantics. Note that this is an INCOMPATIBLE CHANGE: in 8.0 through 8.2, SET LOCAL's effects disappeared at subtransaction commit (leading to behavior that made little sense at the SQL level). I took advantage of the opportunity to rewrite and simplify the GUC variable save/restore logic a little bit. The old idea of a "tentative" value is gone; it was a hangover from before we had a stack. Also, we no longer need a stack entry for every nesting level, but only for those in which a variable's value actually changed.
2007-09-11 02:06:42 +02:00
} GucAction;
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
#define GUC_QUALIFIER_SEPARATOR '.'
Some infrastructure changes for the upcoming auto-explain contrib module: * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
2008-11-19 02:10:24 +01:00
/*
Renumber GUC flags for a bit more sanity. Push the units fields over to the left so that all the single-bit flags can be together. I considered rearranging the single-bit flags to try to group flags with similar purposes, but eventually decided that that involved too many judgment calls. Discussion: https://postgr.es/m/17385-9ee529fb091f0ce5@postgresql.org
2022-09-27 17:51:06 +02:00
* Bit values in "flags" of a GUC variable. Note that these don't appear
* on disk, so we can reassign their values freely.
Some infrastructure changes for the upcoming auto-explain contrib module: * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
2008-11-19 02:10:24 +01:00
*/
Renumber GUC flags for a bit more sanity. Push the units fields over to the left so that all the single-bit flags can be together. I considered rearranging the single-bit flags to try to group flags with similar purposes, but eventually decided that that involved too many judgment calls. Discussion: https://postgr.es/m/17385-9ee529fb091f0ce5@postgresql.org
2022-09-27 17:51:06 +02:00
#define GUC_LIST_INPUT 0x000001 /* input can be list format */
#define GUC_LIST_QUOTE 0x000002 /* double-quote list elements */
#define GUC_NO_SHOW_ALL 0x000004 /* exclude from SHOW ALL */
#define GUC_NO_RESET 0x000008 /* disallow RESET and SAVE */
#define GUC_NO_RESET_ALL 0x000010 /* exclude from RESET ALL */
#define GUC_EXPLAIN 0x000020 /* include in EXPLAIN */
#define GUC_REPORT 0x000040 /* auto-report changes to client */
#define GUC_NOT_IN_SAMPLE 0x000080 /* not in postgresql.conf.sample */
#define GUC_DISALLOW_IN_FILE 0x000100 /* can't set in postgresql.conf */
#define GUC_CUSTOM_PLACEHOLDER 0x000200 /* placeholder for custom variable */
#define GUC_SUPERUSER_ONLY 0x000400 /* show only to superusers */
#define GUC_IS_NAME 0x000800 /* limit string to NAMEDATALEN-1 */
#define GUC_NOT_WHILE_SEC_REST 0x001000 /* can't set if security restricted */
#define GUC_DISALLOW_IN_AUTO_FILE \
0x002000 /* can't set in PG_AUTOCONF_FILENAME */
#define GUC_RUNTIME_COMPUTED 0x004000 /* delay processing in 'postgres -C' */
#define GUC_UNIT_KB 0x01000000 /* value is in kilobytes */
#define GUC_UNIT_BLOCKS 0x02000000 /* value is in blocks */
#define GUC_UNIT_XBLOCKS 0x03000000 /* value is in xlog blocks */
#define GUC_UNIT_MB 0x04000000 /* value is in megabytes */
#define GUC_UNIT_BYTE 0x05000000 /* value is in bytes */
#define GUC_UNIT_MEMORY 0x0F000000 /* mask for size-related units */
#define GUC_UNIT_MS 0x10000000 /* value is in milliseconds */
#define GUC_UNIT_S 0x20000000 /* value is in seconds */
#define GUC_UNIT_MIN 0x30000000 /* value is in minutes */
#define GUC_UNIT_TIME 0x70000000 /* mask for time-related units */
#define GUC_UNIT (GUC_UNIT_MEMORY | GUC_UNIT_TIME)
Refactor unit conversions code in guc.c. Replace the if-switch-case constructs with two conversion tables, containing all the supported conversions between human-readable unit strings and the base units used in GUC variables. This makes the code easier to read, and makes adding new units simpler.
2015-02-23 17:06:16 +01:00
Disallow RESET ROLE and RESET SESSION AUTHORIZATION inside security-definer functions. This extends the previous patch that forbade SETting these variables inside security-definer functions. RESET is equally a security hole, since it would allow regaining privileges of the caller; furthermore it can trigger Assert failures and perhaps other internal errors, since the code is not expecting these variables to change in such contexts. The previous patch did not cover this case because assign hooks don't really have enough information, so move the responsibility for preventing this into guc.c. Problem discovered by Heikki Linnakangas. Security: no CVE assigned yet, extends CVE-2007-6600
2009-09-04 00:08:05 +02:00
Split up guc.c for better build speed and ease of maintenance. guc.c has grown to be one of our largest .c files, making it a bottleneck for compilation. It's also acquired a bunch of knowledge that'd be better kept elsewhere, because of our not very good habit of putting variable-specific check hooks here. Hence, split it up along these lines: * guc.c itself retains just the core GUC housekeeping mechanisms. * New file guc_funcs.c contains the SET/SHOW interfaces and some SQL-accessible functions for GUC manipulation. * New file guc_tables.c contains the data arrays that define the built-in GUC variables, along with some already-exported constant tables. * GUC check/assign/show hook functions are moved to the variable's home module, whenever that's clearly identifiable. A few hard- to-classify hooks ended up in commands/variable.c, which was already a home for miscellaneous GUC hook functions. To avoid cluttering a lot more header files with #include "guc.h", I also invented a new header file utils/guc_hooks.h and put all the GUC hook functions' declarations there, regardless of their originating module. That allowed removal of #include "guc.h" from some existing headers. The fallout from that (hopefully all caught here) demonstrates clearly why such inclusions are best minimized: there are a lot of files that, for example, were getting array.h at two or more levels of remove, despite not having any connection at all to GUCs in themselves. There is some very minor code beautification here, such as renaming a couple of inconsistently-named hook functions and improving some comments. But mostly this just moves code from point A to point B and deals with the ensuing needs for #include adjustments and exporting a few functions that previously weren't exported. Patch by me, per a suggestion from Andres Freund; thanks also to Michael Paquier for the idea to invent guc_funcs.c. Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
/* GUC vars that are actually defined in guc_tables.c, rather than elsewhere */
Apply PGDLLIMPORT markings broadly. Up until now, we've had a policy of only marking certain variables in the PostgreSQL header files with PGDLLIMPORT, but now we've decided to mark them all. This means that extensions running on Windows should no longer operate at a disadvantage as compared to extensions running on Linux: if the variable is present in a header file, it should be accessible. Discussion: http://postgr.es/m/CA+TgmoYanc1_FSfimhgiWSqVyP5KKmh5NP2BWNwDhO8Pg2vGYQ@mail.gmail.com
2022-04-08 14:16:38 +02:00
extern PGDLLIMPORT bool Debug_print_plan;
extern PGDLLIMPORT bool Debug_print_parse;
extern PGDLLIMPORT bool Debug_print_rewritten;
extern PGDLLIMPORT bool Debug_pretty_print;
In the continuing saga of FE/BE protocol revisions, add reporting of initial values and runtime changes in selected parameters. This gets rid of the need for an initial 'select pg_client_encoding()' query in libpq, bringing us back to one message transmitted in each direction for a standard connection startup. To allow server version to be sent using the same GUC mechanism that handles other parameters, invent the concept of a never-settable GUC parameter: you can 'show server_version' but it's not settable by any GUC input source. Create 'lc_collate' and 'lc_ctype' never-settable parameters so that people can find out these settings without need for pg_controldata. (These side ideas were all discussed some time ago in pgsql-hackers, but not yet implemented.)
2003-04-25 21:45:10 +02:00
Apply PGDLLIMPORT markings broadly. Up until now, we've had a policy of only marking certain variables in the PostgreSQL header files with PGDLLIMPORT, but now we've decided to mark them all. This means that extensions running on Windows should no longer operate at a disadvantage as compared to extensions running on Linux: if the variable is present in a header file, it should be accessible. Discussion: http://postgr.es/m/CA+TgmoYanc1_FSfimhgiWSqVyP5KKmh5NP2BWNwDhO8Pg2vGYQ@mail.gmail.com
2022-04-08 14:16:38 +02:00
extern PGDLLIMPORT bool log_parser_stats;
extern PGDLLIMPORT bool log_planner_stats;
extern PGDLLIMPORT bool log_executor_stats;
extern PGDLLIMPORT bool log_statement_stats;
extern PGDLLIMPORT bool log_btree_build_stats;
In the continuing saga of FE/BE protocol revisions, add reporting of initial values and runtime changes in selected parameters. This gets rid of the need for an initial 'select pg_client_encoding()' query in libpq, bringing us back to one message transmitted in each direction for a standard connection startup. To allow server version to be sent using the same GUC mechanism that handles other parameters, invent the concept of a never-settable GUC parameter: you can 'show server_version' but it's not settable by any GUC input source. Create 'lc_collate' and 'lc_ctype' never-settable parameters so that people can find out these settings without need for pg_controldata. (These side ideas were all discussed some time ago in pgsql-hackers, but not yet implemented.)
2003-04-25 21:45:10 +02:00
Rename DLLIMPORT macro to PGDLLIMPORT to avoid conflict with third party includes (like tcl) that define DLLIMPORT.
2007-07-25 14:22:54 +02:00
extern PGDLLIMPORT bool check_function_bodies;
Apply PGDLLIMPORT markings broadly. Up until now, we've had a policy of only marking certain variables in the PostgreSQL header files with PGDLLIMPORT, but now we've decided to mark them all. This means that extensions running on Windows should no longer operate at a disadvantage as compared to extensions running on Linux: if the variable is present in a header file, it should be accessible. Discussion: http://postgr.es/m/CA+TgmoYanc1_FSfimhgiWSqVyP5KKmh5NP2BWNwDhO8Pg2vGYQ@mail.gmail.com
2022-04-08 14:16:38 +02:00
extern PGDLLIMPORT bool session_auth_is_superuser;
This patch adds a new GUC var, "default_with_oids", which follows the proposal for eventually deprecating OIDs on user tables that I posted earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or WITHOUT OIDS when dumping a table. The documentation has been updated. Neil Conway
2003-12-01 23:08:02 +01:00
Apply PGDLLIMPORT markings broadly. Up until now, we've had a policy of only marking certain variables in the PostgreSQL header files with PGDLLIMPORT, but now we've decided to mark them all. This means that extensions running on Windows should no longer operate at a disadvantage as compared to extensions running on Linux: if the variable is present in a header file, it should be accessible. Discussion: http://postgr.es/m/CA+TgmoYanc1_FSfimhgiWSqVyP5KKmh5NP2BWNwDhO8Pg2vGYQ@mail.gmail.com
2022-04-08 14:16:38 +02:00
extern PGDLLIMPORT bool log_duration;
extern PGDLLIMPORT int log_parameter_max_length;
extern PGDLLIMPORT int log_parameter_max_length_on_error;
extern PGDLLIMPORT int log_min_error_statement;
Mark assorted variables PGDLLIMPORT. This makes life easier for extension authors who wish to support Windows. Brian Cloutier, slightly amended by me. Discussion: http://postgr.es/m/CAJCy68fscdNhmzFPS4kyO00CADkvXvEa-28H-OtENk-pa2OTWw@mail.gmail.com
2017-12-05 15:23:57 +01:00
extern PGDLLIMPORT int log_min_messages;
extern PGDLLIMPORT int client_min_messages;
Apply PGDLLIMPORT markings broadly. Up until now, we've had a policy of only marking certain variables in the PostgreSQL header files with PGDLLIMPORT, but now we've decided to mark them all. This means that extensions running on Windows should no longer operate at a disadvantage as compared to extensions running on Linux: if the variable is present in a header file, it should be accessible. Discussion: http://postgr.es/m/CA+TgmoYanc1_FSfimhgiWSqVyP5KKmh5NP2BWNwDhO8Pg2vGYQ@mail.gmail.com
2022-04-08 14:16:38 +02:00
extern PGDLLIMPORT int log_min_duration_sample;
extern PGDLLIMPORT int log_min_duration_statement;
extern PGDLLIMPORT int log_temp_files;
extern PGDLLIMPORT double log_statement_sample_rate;
extern PGDLLIMPORT double log_xact_sample_rate;
extern PGDLLIMPORT char *backtrace_functions;
In the continuing saga of FE/BE protocol revisions, add reporting of initial values and runtime changes in selected parameters. This gets rid of the need for an initial 'select pg_client_encoding()' query in libpq, bringing us back to one message transmitted in each direction for a standard connection startup. To allow server version to be sent using the same GUC mechanism that handles other parameters, invent the concept of a never-settable GUC parameter: you can 'show server_version' but it's not settable by any GUC input source. Create 'lc_collate' and 'lc_ctype' never-settable parameters so that people can find out these settings without need for pg_controldata. (These side ideas were all discussed some time ago in pgsql-hackers, but not yet implemented.)
2003-04-25 21:45:10 +02:00
Apply PGDLLIMPORT markings broadly. Up until now, we've had a policy of only marking certain variables in the PostgreSQL header files with PGDLLIMPORT, but now we've decided to mark them all. This means that extensions running on Windows should no longer operate at a disadvantage as compared to extensions running on Linux: if the variable is present in a header file, it should be accessible. Discussion: http://postgr.es/m/CA+TgmoYanc1_FSfimhgiWSqVyP5KKmh5NP2BWNwDhO8Pg2vGYQ@mail.gmail.com
2022-04-08 14:16:38 +02:00
extern PGDLLIMPORT int temp_file_limit;
Add temp_file_limit GUC parameter to constrain temporary file space usage. The limit is enforced against the total amount of temp file space used by each session. Mark Kirkwood, reviewed by Cédric Villemain and Tatsuo Ishii
2011-07-17 20:19:31 +02:00
Apply PGDLLIMPORT markings broadly. Up until now, we've had a policy of only marking certain variables in the PostgreSQL header files with PGDLLIMPORT, but now we've decided to mark them all. This means that extensions running on Windows should no longer operate at a disadvantage as compared to extensions running on Linux: if the variable is present in a header file, it should be accessible. Discussion: http://postgr.es/m/CA+TgmoYanc1_FSfimhgiWSqVyP5KKmh5NP2BWNwDhO8Pg2vGYQ@mail.gmail.com
2022-04-08 14:16:38 +02:00
extern PGDLLIMPORT int num_temp_buffers;
Add temp_buffers GUC variable to allow users to determine the size of the local buffer arena for temporary table access.
2005-03-20 00:27:11 +01:00
postgres_fdw: Make postgres_fdw.application_name support more escape sequences. Commit 6e0cb3dec1 allowed postgres_fdw.application_name to include escape sequences %a (application name), %d (database name), %u (user name) and %p (pid). In addition to them, this commit makes it support the escape sequences for session ID (%c) and cluster name (%C). These are helpful to investigate where each remote transactions came from. Author: Fujii Masao Reviewed-by: Ryohei Takahashi, Kyotaro Horiguchi Discussion: https://postgr.es/m/1041dc9a-c976-049f-9f14-e7d94c29c4b2@oss.nttdata.com
2022-02-18 03:38:12 +01:00
extern PGDLLIMPORT char *cluster_name;
Mark assorted variables PGDLLIMPORT. This makes life easier for extension authors who wish to support Windows. Brian Cloutier, slightly amended by me. Discussion: http://postgr.es/m/CAJCy68fscdNhmzFPS4kyO00CADkvXvEa-28H-OtENk-pa2OTWw@mail.gmail.com
2017-12-05 15:23:57 +01:00
extern PGDLLIMPORT char *ConfigFileName;
Apply PGDLLIMPORT markings broadly. Up until now, we've had a policy of only marking certain variables in the PostgreSQL header files with PGDLLIMPORT, but now we've decided to mark them all. This means that extensions running on Windows should no longer operate at a disadvantage as compared to extensions running on Linux: if the variable is present in a header file, it should be accessible. Discussion: http://postgr.es/m/CA+TgmoYanc1_FSfimhgiWSqVyP5KKmh5NP2BWNwDhO8Pg2vGYQ@mail.gmail.com
2022-04-08 14:16:38 +02:00
extern PGDLLIMPORT char *HbaFileName;
extern PGDLLIMPORT char *IdentFileName;
extern PGDLLIMPORT char *external_pid_file;
Allow configuration files to be placed outside the data directory. Add new postgresql.conf variables to point to data, pg_hba.conf, and pg_ident.conf files. Needs more documentation.
2004-07-11 02:18:45 +02:00
Mark assorted GUC variables as PGDLLIMPORT. This makes life easier for extension authors. Metin Doslu Discussion: http://postgr.es/m/CAL1dPcfa45o1dC-c4t-48v0OZE6oy4ChJhObrtkK8mzNfXqDTA@mail.gmail.com
2018-02-09 21:54:45 +01:00
extern PGDLLIMPORT char *application_name;
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
Apply PGDLLIMPORT markings broadly. Up until now, we've had a policy of only marking certain variables in the PostgreSQL header files with PGDLLIMPORT, but now we've decided to mark them all. This means that extensions running on Windows should no longer operate at a disadvantage as compared to extensions running on Linux: if the variable is present in a header file, it should be accessible. Discussion: http://postgr.es/m/CA+TgmoYanc1_FSfimhgiWSqVyP5KKmh5NP2BWNwDhO8Pg2vGYQ@mail.gmail.com
2022-04-08 14:16:38 +02:00
extern PGDLLIMPORT int tcp_keepalives_idle;
extern PGDLLIMPORT int tcp_keepalives_interval;
extern PGDLLIMPORT int tcp_keepalives_count;
extern PGDLLIMPORT int tcp_user_timeout;
In the continuing saga of FE/BE protocol revisions, add reporting of initial values and runtime changes in selected parameters. This gets rid of the need for an initial 'select pg_client_encoding()' query in libpq, bringing us back to one message transmitted in each direction for a standard connection startup. To allow server version to be sent using the same GUC mechanism that handles other parameters, invent the concept of a never-settable GUC parameter: you can 'show server_version' but it's not settable by any GUC input source. Create 'lc_collate' and 'lc_ctype' never-settable parameters so that people can find out these settings without need for pg_controldata. (These side ideas were all discussed some time ago in pgsql-hackers, but not yet implemented.)
2003-04-25 21:45:10 +02:00
Use abbreviated keys for faster sorting of numeric datums. Andrew Gierth, reviewed by Peter Geoghegan, with further tweaks by me.
2015-04-02 20:02:55 +02:00
#ifdef TRACE_SORT
Apply PGDLLIMPORT markings broadly. Up until now, we've had a policy of only marking certain variables in the PostgreSQL header files with PGDLLIMPORT, but now we've decided to mark them all. This means that extensions running on Windows should no longer operate at a disadvantage as compared to extensions running on Linux: if the variable is present in a header file, it should be accessible. Discussion: http://postgr.es/m/CA+TgmoYanc1_FSfimhgiWSqVyP5KKmh5NP2BWNwDhO8Pg2vGYQ@mail.gmail.com
2022-04-08 14:16:38 +02:00
extern PGDLLIMPORT bool trace_sort;
Use abbreviated keys for faster sorting of numeric datums. Andrew Gierth, reviewed by Peter Geoghegan, with further tweaks by me.
2015-04-02 20:02:55 +02:00
#endif
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
/*
* Functions exported by guc.c
*/
Extend GUC concepts of parse_hook and assign_hook to all four supported datatypes, not only strings. parse_hook is useless for bool, I suppose, but it seems possibly useful for int and double to apply variable-specific constraints that are more complex than simple range limits. assign_hook is definitely useful for all datatypes --- we need it right now for bool to support date cache reset when changing Australian timezone rule setting. Also, clean up some residual problems with the reset all/show all patch, including memory leaks and mistaken reset of PostPortNumber. It seems best that RESET ALL not touch variables that don't have SUSET or USERSET context.
2001-06-13 00:54:06 +02:00
extern void SetConfigOption(const char *name, const char *value,
Save source of GUC settings, allowing different sources to be processed in any order without affecting results.
2002-02-23 02:31:37 +01:00
GucContext context, GucSource source);
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
Remove superfluous newlines in function prototypes. These were introduced by pgindent due to fixe to broken indentation (c.f. 8255c7a5eeba8). Previously the mis-indentation of function prototypes was creatively used to reduce indentation in a few places. As that formatting only exists in master and REL_12_STABLE, it seems better to fix it in both, rather than having some odd indentation in v12 that somebody might copy for future patches or such. Author: Andres Freund Discussion: https://postgr.es/m/20190728013754.jwcbe5nfyt3533vx@alap3.anarazel.de Backpatch: 12-
2019-07-31 09:05:21 +02:00
extern void DefineCustomBoolVariable(const char *name,
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
const char *short_desc,
const char *long_desc,
bool *valueAddr,
Some infrastructure changes for the upcoming auto-explain contrib module: * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
2008-11-19 02:10:24 +01:00
bool bootValue,
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
GucContext context,
Some infrastructure changes for the upcoming auto-explain contrib module: * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
2008-11-19 02:10:24 +01:00
int flags,
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
GucBoolCheckHook check_hook,
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
GucBoolAssignHook assign_hook,
Introduce pg_attribute_nonnull(...) pg_attribute_nonnull(...) can be used to generate compiler warnings when a function is called with the specified arguments set to NULL, as per an idea from Andres Freund. An empty argument list indicates that no pointer arguments can be NULL. pg_attribute_nonnull() only works for compilers that support the nonnull function attribute. If nonnull is not supported, pg_attribute_nonnull() has no effect. As a beginning, this commit uses it for the DefineCustomXXXVariable() functions to generate warnings when the "name" and "value" arguments are set to NULL. This will likely be expanded to other places in the future, where it makes sense. Author: Nathan Bossart Reviewed by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/20220525061739.ur7x535vtzyzkmqo@alap3.anarazel.de
2022-07-02 05:30:45 +02:00
GucShowHook show_hook) pg_attribute_nonnull(1, 4);
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
Remove superfluous newlines in function prototypes. These were introduced by pgindent due to fixe to broken indentation (c.f. 8255c7a5eeba8). Previously the mis-indentation of function prototypes was creatively used to reduce indentation in a few places. As that formatting only exists in master and REL_12_STABLE, it seems better to fix it in both, rather than having some odd indentation in v12 that somebody might copy for future patches or such. Author: Andres Freund Discussion: https://postgr.es/m/20190728013754.jwcbe5nfyt3533vx@alap3.anarazel.de Backpatch: 12-
2019-07-31 09:05:21 +02:00
extern void DefineCustomIntVariable(const char *name,
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
const char *short_desc,
const char *long_desc,
int *valueAddr,
Some infrastructure changes for the upcoming auto-explain contrib module: * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
2008-11-19 02:10:24 +01:00
int bootValue,
Add missing min/max parameters to DefineCustomIntVariable() and DefineCustomRealVariable(). Thomas Hallgren
2005-03-25 17:17:28 +01:00
int minValue,
int maxValue,
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
GucContext context,
Some infrastructure changes for the upcoming auto-explain contrib module: * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
2008-11-19 02:10:24 +01:00
int flags,
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
GucIntCheckHook check_hook,
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
GucIntAssignHook assign_hook,
Introduce pg_attribute_nonnull(...) pg_attribute_nonnull(...) can be used to generate compiler warnings when a function is called with the specified arguments set to NULL, as per an idea from Andres Freund. An empty argument list indicates that no pointer arguments can be NULL. pg_attribute_nonnull() only works for compilers that support the nonnull function attribute. If nonnull is not supported, pg_attribute_nonnull() has no effect. As a beginning, this commit uses it for the DefineCustomXXXVariable() functions to generate warnings when the "name" and "value" arguments are set to NULL. This will likely be expanded to other places in the future, where it makes sense. Author: Nathan Bossart Reviewed by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/20220525061739.ur7x535vtzyzkmqo@alap3.anarazel.de
2022-07-02 05:30:45 +02:00
GucShowHook show_hook) pg_attribute_nonnull(1, 4);
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
Remove superfluous newlines in function prototypes. These were introduced by pgindent due to fixe to broken indentation (c.f. 8255c7a5eeba8). Previously the mis-indentation of function prototypes was creatively used to reduce indentation in a few places. As that formatting only exists in master and REL_12_STABLE, it seems better to fix it in both, rather than having some odd indentation in v12 that somebody might copy for future patches or such. Author: Andres Freund Discussion: https://postgr.es/m/20190728013754.jwcbe5nfyt3533vx@alap3.anarazel.de Backpatch: 12-
2019-07-31 09:05:21 +02:00
extern void DefineCustomRealVariable(const char *name,
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
const char *short_desc,
const char *long_desc,
double *valueAddr,
Some infrastructure changes for the upcoming auto-explain contrib module: * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
2008-11-19 02:10:24 +01:00
double bootValue,
Add missing min/max parameters to DefineCustomIntVariable() and DefineCustomRealVariable(). Thomas Hallgren
2005-03-25 17:17:28 +01:00
double minValue,
double maxValue,
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
GucContext context,
Some infrastructure changes for the upcoming auto-explain contrib module: * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
2008-11-19 02:10:24 +01:00
int flags,
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
GucRealCheckHook check_hook,
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
GucRealAssignHook assign_hook,
Introduce pg_attribute_nonnull(...) pg_attribute_nonnull(...) can be used to generate compiler warnings when a function is called with the specified arguments set to NULL, as per an idea from Andres Freund. An empty argument list indicates that no pointer arguments can be NULL. pg_attribute_nonnull() only works for compilers that support the nonnull function attribute. If nonnull is not supported, pg_attribute_nonnull() has no effect. As a beginning, this commit uses it for the DefineCustomXXXVariable() functions to generate warnings when the "name" and "value" arguments are set to NULL. This will likely be expanded to other places in the future, where it makes sense. Author: Nathan Bossart Reviewed by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/20220525061739.ur7x535vtzyzkmqo@alap3.anarazel.de
2022-07-02 05:30:45 +02:00
GucShowHook show_hook) pg_attribute_nonnull(1, 4);
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
Remove superfluous newlines in function prototypes. These were introduced by pgindent due to fixe to broken indentation (c.f. 8255c7a5eeba8). Previously the mis-indentation of function prototypes was creatively used to reduce indentation in a few places. As that formatting only exists in master and REL_12_STABLE, it seems better to fix it in both, rather than having some odd indentation in v12 that somebody might copy for future patches or such. Author: Andres Freund Discussion: https://postgr.es/m/20190728013754.jwcbe5nfyt3533vx@alap3.anarazel.de Backpatch: 12-
2019-07-31 09:05:21 +02:00
extern void DefineCustomStringVariable(const char *name,
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
const char *short_desc,
const char *long_desc,
char **valueAddr,
Some infrastructure changes for the upcoming auto-explain contrib module: * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
2008-11-19 02:10:24 +01:00
const char *bootValue,
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
GucContext context,
Some infrastructure changes for the upcoming auto-explain contrib module: * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
2008-11-19 02:10:24 +01:00
int flags,
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
GucStringCheckHook check_hook,
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
GucStringAssignHook assign_hook,
Introduce pg_attribute_nonnull(...) pg_attribute_nonnull(...) can be used to generate compiler warnings when a function is called with the specified arguments set to NULL, as per an idea from Andres Freund. An empty argument list indicates that no pointer arguments can be NULL. pg_attribute_nonnull() only works for compilers that support the nonnull function attribute. If nonnull is not supported, pg_attribute_nonnull() has no effect. As a beginning, this commit uses it for the DefineCustomXXXVariable() functions to generate warnings when the "name" and "value" arguments are set to NULL. This will likely be expanded to other places in the future, where it makes sense. Author: Nathan Bossart Reviewed by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/20220525061739.ur7x535vtzyzkmqo@alap3.anarazel.de
2022-07-02 05:30:45 +02:00
GucShowHook show_hook) pg_attribute_nonnull(1, 4);
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
Remove superfluous newlines in function prototypes. These were introduced by pgindent due to fixe to broken indentation (c.f. 8255c7a5eeba8). Previously the mis-indentation of function prototypes was creatively used to reduce indentation in a few places. As that formatting only exists in master and REL_12_STABLE, it seems better to fix it in both, rather than having some odd indentation in v12 that somebody might copy for future patches or such. Author: Andres Freund Discussion: https://postgr.es/m/20190728013754.jwcbe5nfyt3533vx@alap3.anarazel.de Backpatch: 12-
2019-07-31 09:05:21 +02:00
extern void DefineCustomEnumVariable(const char *name,
Some cleanups of enum-guc code, per comments from Tom.
2008-03-16 17:42:44 +01:00
const char *short_desc,
const char *long_desc,
int *valueAddr,
Some infrastructure changes for the upcoming auto-explain contrib module: * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
2008-11-19 02:10:24 +01:00
int bootValue,
Some cleanups of enum-guc code, per comments from Tom.
2008-03-16 17:42:44 +01:00
const struct config_enum_entry *options,
GucContext context,
Some infrastructure changes for the upcoming auto-explain contrib module: * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
2008-11-19 02:10:24 +01:00
int flags,
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
GucEnumCheckHook check_hook,
Some cleanups of enum-guc code, per comments from Tom.
2008-03-16 17:42:44 +01:00
GucEnumAssignHook assign_hook,
Introduce pg_attribute_nonnull(...) pg_attribute_nonnull(...) can be used to generate compiler warnings when a function is called with the specified arguments set to NULL, as per an idea from Andres Freund. An empty argument list indicates that no pointer arguments can be NULL. pg_attribute_nonnull() only works for compilers that support the nonnull function attribute. If nonnull is not supported, pg_attribute_nonnull() has no effect. As a beginning, this commit uses it for the DefineCustomXXXVariable() functions to generate warnings when the "name" and "value" arguments are set to NULL. This will likely be expanded to other places in the future, where it makes sense. Author: Nathan Bossart Reviewed by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/20220525061739.ur7x535vtzyzkmqo@alap3.anarazel.de
2022-07-02 05:30:45 +02:00
GucShowHook show_hook) pg_attribute_nonnull(1, 4);
Some cleanups of enum-guc code, per comments from Tom.
2008-03-16 17:42:44 +01:00
Disallow setting bogus GUCs within an extension's reserved namespace. Commit 75d22069e tried to throw a warning for setting a custom GUC whose prefix belongs to a previously-loaded extension, if there is no such GUC defined by the extension. But that caused unstable behavior with parallel workers, because workers don't necessarily load extensions and GUCs in the same order their leader did. To make that work safely, we have to completely disallow the case. We now actually remove any such GUCs at the time of initial extension load, and then throw an error not just a warning if you try to add one later. While this might create a compatibility issue for a few people, the improvement in error-detection capability seems worth it; it's hard to believe that there's any good use-case for choosing such GUC names. This also un-reverts 5609cc01c (Rename EmitWarningsOnPlaceholders() to MarkGUCPrefixReserved()), since that function's old name is now even more of a misnomer. Florin Irion and Tom Lane Discussion: https://postgr.es/m/1902182.1640711215@sss.pgh.pa.us
2022-02-21 20:10:15 +01:00
extern void MarkGUCPrefixReserved(const char *className);
/* old name for MarkGUCPrefixReserved, for backwards compatibility: */
#define EmitWarningsOnPlaceholders(className) MarkGUCPrefixReserved(className)
The patch adresses the TODO list item "Allow external interfaces to extend the GUC variable set". Plugin modules like the pl<lang> modules needs a way to declare configuration parameters. The postmaster has no knowledge of such modules when it reads the postgresql.conf file. Rather than allowing totally unknown configuration parameters, the concept of a variable "class" is introduced. Variables that belongs to a declared classes will create a placeholder value of string type and will not generate an error. When a module is loaded, it will declare variables for such a class and make those variables "consume" any placeholders that has been defined. Finally, the module will generate warnings for unrecognized placeholders defined for its class. More detail: The design is outlined after the suggestions made by Tom Lane and Joe Conway in this thread: http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php A new string variable 'custom_variable_classes' is introduced. This variable is a comma separated string of identifiers. Each identifier denots a 'class' that will allow its members to be added without error. This variable must be defined in postmaster.conf. The lexer (guc_file.l) is changed so that it can accept a qualified name in the form <ID>.<ID> as the name of a variable. I also changed so that the 'custom_variable_classes', if found, is added first of all variables in order to remove the order of declaration issue. The guc_variables table is made more dynamic. It is originally created with 20% slack and can grow dynamically. A capacity is introduced to avoid resizing every time a new variable is added. guc_variables and num_guc_variables becomes static (hidden). The GucInfoMain now uses the new function get_guc_variables() and GetNumConfigOptions instead or using the guc_variables directly. The find_option() function, when passed a missing name, will check if the name is qualified. If the name is qualified and if the qualifier denotes a class included in the 'custom_variable_classes', a placeholder variable will be created. Such a placeholder will not participate in a list operation but will otherwise function as a normal string variable. Define<type>GucVariable() functions will be added, one for each variable type. They are inteded to be used by add-on modules like the pl<lang> mappings. Example: extern void DefineCustomBoolVariable( const char* name, const char* short_desc, const char* long_desc, bool* valueAddr, GucContext context, GucBoolAssignHook assign_hook, GucShowHook show_hook); (I created typedefs for the assign-hook and show-hook functions). A call to these functions will define a new GUC-variable. If a placeholder exists it will be replaced but it's value will be used in place of the default value. The valueAddr is assumed ot point at a default value when the define function is called. The only constraint that is imposed on a Custom variable is that its name is qualified. Finally, a function: void EmittWarningsOnPlacholders(const char* className) was added. This function should be called when a module has completed its variable definitions. At that time, no placeholders should remain for the class that the module uses. If they do, elog(INFO, ...) messages will be issued to inform the user that unrecognized variables are present. Thomas Hallgren
2004-05-26 17:07:41 +02:00
Fix another oversight in logging of changes in postgresql.conf settings. We were using GetConfigOption to collect the old value of each setting, overlooking the possibility that it didn't exist yet. This does happen in the case of adding a new entry within a custom variable class, as exhibited in bug #6097 from Maxim Boguk. To fix, add a missing_ok parameter to GetConfigOption, but only in 9.1 and HEAD --- it seems possible that some third-party code is using that function, so changing its API in a minor release would cause problems. In 9.0, create a near-duplicate function instead.
2011-07-08 23:02:58 +02:00
extern const char *GetConfigOption(const char *name, bool missing_ok,
Teach SHOW ALL to honor pg_read_all_settings membership Also, fix the pg_settings view to display source filename and line number when invoked by a pg_read_all_settings member. This addition by me (Álvaro). Also, fix wording of the comment in GetConfigOption regarding the restriction it implements, renaming the parameter for extra clarity. Noted by Michaël. These were all oversight in commit 25fff40798fc; backpatch to pg10, where that commit first appeared. Author: Laurenz Albe Reviewed-by: Michaël Paquier, Álvaro Herrera Discussion: https://postgr.es/m/1519917758.6586.8.camel@cybertec.at
2018-06-08 22:18:40 +02:00
bool restrict_privileged);
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
extern const char *GetConfigOptionResetString(const char *name);
Fix mishandling of quoted-list GUC values in pg_dump and ruleutils.c. Code that prints out the contents of setconfig or proconfig arrays in SQL format needs to handle GUC_LIST_QUOTE variables differently from other ones, because for those variables, flatten_set_variable_args() already applied a layer of quoting. The value can therefore safely be printed as-is, and indeed must be, or flatten_set_variable_args() will muck it up completely on reload. For all other GUC variables, it's necessary and sufficient to quote the value as a SQL literal. We'd recognized the need for this long ago, but mis-analyzed the need slightly, thinking that all GUC_LIST_INPUT variables needed the special treatment. That's actually wrong, since a valid value of a LIST variable might include characters that need quoting, although no existing variables accept such values. More to the point, we hadn't made any particular effort to keep the various places that deal with this up-to-date with the set of variables that actually need special treatment, meaning that we'd do the wrong thing with, for example, temp_tablespaces values. This affects dumping of SET clauses attached to functions, as well as ALTER DATABASE/ROLE SET commands. In ruleutils.c we can fix it reasonably honestly by exporting a guc.c function that allows discovering the flags for a given GUC variable. But pg_dump doesn't have easy access to that, so continue the old method of having a hard-wired list of affected variable names. At least we can fix it to have just one list not two, and update the list to match current reality. A remaining problem with this is that it only works for built-in GUC variables. pg_dump's list obvious knows nothing of third-party extensions, and even the "ask guc.c" method isn't bulletproof since the relevant extension might not be loaded. There's no obvious solution to that, so for now, we'll just have to discourage extension authors from inventing custom GUCs that need GUC_LIST_QUOTE. This has been busted for a long time, so back-patch to all supported branches. Michael Paquier and Tom Lane, reviewed by Kyotaro Horiguchi and Pavel Stehule Discussion: https://postgr.es/m/20180111064900.GA51030@paquier.xyz
2018-03-22 01:03:28 +01:00
extern int GetConfigOptionFlags(const char *name, bool missing_ok);
Extend GUC concepts of parse_hook and assign_hook to all four supported datatypes, not only strings. parse_hook is useless for bool, I suppose, but it seems possibly useful for int and double to apply variable-specific constraints that are more complex than simple range limits. assign_hook is definitely useful for all datatypes --- we need it right now for bool to support date cache reset when changing Australian timezone rule setting. Also, clean up some residual problems with the reset all/show all patch, including memory leaks and mistaken reset of PostPortNumber. It seems best that RESET ALL not touch variables that don't have SUSET or USERSET context.
2001-06-13 00:54:06 +02:00
extern void ProcessConfigFile(GucContext context);
Allow granting SET and ALTER SYSTEM privileges on GUC parameters. This patch allows "PGC_SUSET" parameters to be set by non-superusers if they have been explicitly granted the privilege to do so. The privilege to perform ALTER SYSTEM SET/RESET on a specific parameter can also be granted. Such privileges are cluster-wide, not per database. They are tracked in a new shared catalog, pg_parameter_acl. Granting and revoking these new privileges works as one would expect. One caveat is that PGC_USERSET GUCs are unaffected by the SET privilege --- one could wish that those were handled by a revocable grant to PUBLIC, but they are not, because we couldn't make it robust enough for GUCs defined by extensions. Mark Dilger, reviewed at various times by Andrew Dunstan, Robert Haas, Joshua Brindle, and myself Discussion: https://postgr.es/m/3D691E20-C1D5-4B80-8BA5-6BEB63AF3029@enterprisedb.com
2022-04-06 19:24:33 +02:00
extern char *convert_GUC_name_for_parameter_acl(const char *name);
extern bool check_GUC_name_for_parameter_acl(const char *name);
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
extern void InitializeGUCOptions(void);
Whack some sense into the configuration-file-location patch. Refactor code into something reasonably understandable, cause use of the feature to not fail in standalone backends or in EXEC_BACKEND case, fix sloppy guc.c table entries, make the documentation minimally usable.
2004-10-08 03:36:36 +02:00
extern bool SelectConfigFiles(const char *userDoption, const char *progname);
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
extern void ResetAllOptions(void);
Implement function-local GUC parameter settings, as per recent discussion. There are still some loose ends: I didn't do anything about the SET FROM CURRENT idea yet, and it's not real clear whether we are happy with the interaction of SET LOCAL with function-local settings. The documentation is a bit spartan, too.
2007-09-03 02:39:26 +02:00
extern void AtStart_GUC(void);
extern int NewGUCNestLevel(void);
extern void AtEOXact_GUC(bool isCommit, int nestLevel);
In the continuing saga of FE/BE protocol revisions, add reporting of initial values and runtime changes in selected parameters. This gets rid of the need for an initial 'select pg_client_encoding()' query in libpq, bringing us back to one message transmitted in each direction for a standard connection startup. To allow server version to be sent using the same GUC mechanism that handles other parameters, invent the concept of a never-settable GUC parameter: you can 'show server_version' but it's not settable by any GUC input source. Create 'lc_collate' and 'lc_ctype' never-settable parameters so that people can find out these settings without need for pg_controldata. (These side ideas were all discussed some time ago in pgsql-hackers, but not yet implemented.)
2003-04-25 21:45:10 +02:00
extern void BeginReportingGUCOptions(void);
Avoid spamming the client with multiple ParameterStatus messages. Up to now, we sent a ParameterStatus message to the client immediately upon any change in the active value of any GUC_REPORT variable. This was only barely okay when the feature was designed; now that we have things like function SET clauses, there are very plausible use-cases where a GUC_REPORT variable might change many times within a query --- and even end up back at its original value, perhaps. Fortunately most of our GUC_REPORT variables are unlikely to be changed often; but there are proposals in play to enlarge that set, or even make it user-configurable. Hence, let's fix things to not generate more than one ParameterStatus message per variable per query, and to not send any message at all unless the end-of-query value is different from what we last reported. Discussion: https://postgr.es/m/5708.1601145259@sss.pgh.pa.us
2020-11-25 17:40:44 +01:00
extern void ReportChangedGUCOptions(void);
Extend GUC concepts of parse_hook and assign_hook to all four supported datatypes, not only strings. parse_hook is useless for bool, I suppose, but it seems possibly useful for int and double to apply variable-specific constraints that are more complex than simple range limits. assign_hook is definitely useful for all datatypes --- we need it right now for bool to support date cache reset when changing Australian timezone rule setting. Also, clean up some residual problems with the reset all/show all patch, including memory leaks and mistaken reset of PostPortNumber. It seems best that RESET ALL not touch variables that don't have SUSET or USERSET context.
2001-06-13 00:54:06 +02:00
extern void ParseLongOption(const char *string, char **name, char **value);
Split up guc.c for better build speed and ease of maintenance. guc.c has grown to be one of our largest .c files, making it a bottleneck for compilation. It's also acquired a bunch of knowledge that'd be better kept elsewhere, because of our not very good habit of putting variable-specific check hooks here. Hence, split it up along these lines: * guc.c itself retains just the core GUC housekeeping mechanisms. * New file guc_funcs.c contains the SET/SHOW interfaces and some SQL-accessible functions for GUC manipulation. * New file guc_tables.c contains the data arrays that define the built-in GUC variables, along with some already-exported constant tables. * GUC check/assign/show hook functions are moved to the variable's home module, whenever that's clearly identifiable. A few hard- to-classify hooks ended up in commands/variable.c, which was already a home for miscellaneous GUC hook functions. To avoid cluttering a lot more header files with #include "guc.h", I also invented a new header file utils/guc_hooks.h and put all the GUC hook functions' declarations there, regardless of their originating module. That allowed removal of #include "guc.h" from some existing headers. The fallout from that (hopefully all caught here) demonstrates clearly why such inclusions are best minimized: there are a lot of files that, for example, were getting array.h at two or more levels of remove, despite not having any connection at all to GUCs in themselves. There is some very minor code beautification here, such as renaming a couple of inconsistently-named hook functions and improving some comments. But mostly this just moves code from point A to point B and deals with the ensuing needs for #include adjustments and exporting a few functions that previously weren't exported. Patch by me, per a suggestion from Andres Freund; thanks also to Michael Paquier for the idea to invent guc_funcs.c. Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
extern const char *get_config_unit_name(int flags);
Use guc.c's parse_int() instead of pg_atoi() to parse fillfactor in default_reloptions(). The previous coding was really a bug because pg_atoi() will always throw elog on bad input data, whereas default_reloptions is not supposed to complain about bad input unless its validate parameter is true. Right now you could only expose the problem by hand-modifying pg_class.reloptions into an invalid state, so it doesn't seem worth back-patching; but we should get it right in HEAD because there might be other situations in future. Noted while studying GIN fast-update patch.
2008-07-23 19:29:53 +02:00
extern bool parse_int(const char *value, int *result, int flags,
const char **hintmsg);
Convert [autovacuum_]vacuum_cost_delay into floating-point GUCs. This change makes it possible to specify sub-millisecond delays, which work well on most modern platforms, though that was not true when the cost-delay feature was designed. To support this without breaking existing configuration entries, improve guc.c to allow floating-point GUCs to have units. Also, allow "us" (microseconds) as an input/output unit for time-unit GUCs. (It's not allowed as a base unit, at least not yet.) Likewise change the autovacuum_vacuum_cost_delay reloption to be floating-point; this forces a catversion bump because the layout of StdRdOptions changes. This patch doesn't in itself change the default values or allowed ranges for these parameters, and it should not affect the behavior for any already-allowed setting for them. Discussion: https://postgr.es/m/1798.1552165479@sss.pgh.pa.us
2019-03-10 20:01:39 +01:00
extern bool parse_real(const char *value, double *result, int flags,
const char **hintmsg);
Restructure error handling in reading of postgresql.conf. This patch has two distinct purposes: to report multiple problems in postgresql.conf rather than always bailing out after the first one, and to change the policy for whether changes are applied when there are unrelated errors in postgresql.conf. Formerly the policy was to apply no changes if any errors could be detected, but that had a significant consistency problem, because in some cases specific values might be seen as valid by some processes but invalid by others. This meant that the latter processes would fail to adopt changes in other parameters even though the former processes had done so. The new policy is that during SIGHUP, the file is rejected as a whole if there are any errors in the "name = value" syntax, or if any lines attempt to set nonexistent built-in parameters, or if any lines attempt to set custom parameters whose prefix is not listed in (the new value of) custom_variable_classes. These tests should always give the same results in all processes, and provide what seems a reasonably robust defense against loading values from badly corrupted config files. If these tests pass, all processes will apply all settings that they individually see as good, ignoring (but logging) any they don't. In addition, the postmaster does not abandon reading a configuration file after the first syntax error, but continues to read the file and report syntax errors (up to a maximum of 100 syntax errors per file). The postmaster will still refuse to start up if the configuration file contains any errors at startup time, but these changes allow multiple errors to be detected and reported before quitting. Alexey Klyukin, reviewed by Andy Colson and av (Alexander ?) with some additional hacking by Tom Lane
2011-10-02 22:50:04 +02:00
extern int set_config_option(const char *name, const char *value,
Merge the last few variable.c configuration variables into the generic GUC support. It's now possible to set datestyle, timezone, and client_encoding from postgresql.conf and per-database or per-user settings. Also, implement rollback of SET commands that occur in a transaction that later fails. Create a SET LOCAL var = value syntax that sets the variable only for the duration of the current transaction. All per previous discussions in pghackers.
2002-05-17 03:19:19 +02:00
GucContext context, GucSource source,
Add infrastructure to save and restore GUC values. This is further infrastructure for parallelism. Amit Khandekar, Noah Misch, Robert Haas
2014-11-24 22:13:11 +01:00
GucAction action, bool changeVal, int elevel,
bool is_reload);
Fix missed corner cases for grantable permissions on GUCs. We allow users to set the values of not-yet-loaded extension GUCs, remembering those values in "placeholder" GUC entries. When/if the extension is loaded later in the session, we need to verify that the user had permissions to set the GUC. That was done correctly before commit a0ffa885e, but as of that commit, we'd check the permissions of the active role when the LOAD happens, not the role that had set the value. (This'd be a security bug if it had made it into a released version.) In principle this is simple enough to fix: we just need to remember the exact role OID that set each GUC value, and use that not GetUserID() when verifying permissions. Maintaining that data in the guc.c data structures is slightly tedious, but fortunately it's all basically just copy-n-paste of the logic for tracking the GucSource of each setting, as we were already doing. Another oversight is that validate_option_array_item() hadn't been taught to check for granted GUC privileges. This appears to manifest only in that ALTER ROLE/DATABASE RESET ALL will fail to reset settings that the user should be allowed to reset. Patch by myself and Nathan Bossart, per report from Nathan Bossart. Back-patch to v15 where the faulty code came in. Discussion: https://postgr.es/m/20220706224727.GA2158260@nathanxps13
2022-07-19 23:21:55 +02:00
extern int set_config_option_ext(const char *name, const char *value,
GucContext context, GucSource source,
Oid srole,
GucAction action, bool changeVal, int elevel,
bool is_reload);
Fix inconsistencies and typos in the tree, take 10 This addresses some issues with unnecessary code comments, fixes various typos in docs and comments, and removes some orphaned structures and definitions. Author: Alexander Lakhin Discussion: https://postgr.es/m/9aabc775-5494-b372-8bcb-4dfc0bd37c68@gmail.com
2019-08-13 06:53:41 +02:00
extern void AlterSystemSetConfigFile(AlterSystemStmt *altersysstmt);
Add an optional missing_ok argument to SQL function current_setting(). This allows convenient checking for existence of a GUC from SQL, which is particularly useful when dealing with custom variables. David Christensen, reviewed by Jeevan Chalke
2015-07-02 22:40:55 +02:00
extern char *GetConfigOptionByName(const char *name, const char **varname,
bool missing_ok);
The heralded `Grand Unified Configuration scheme' (GUC) That means you can now set your options in either or all of $PGDATA/configuration, some postmaster option (--enable-fsync=off), or set a SET command. The list of options is in backend/utils/misc/guc.c, documentation will be written post haste. pg_options is gone, so is that pq_geqo config file. Also removed were backend -K, -Q, and -T options (no longer applicable, although -d0 does the same as -Q). Added to configure an --enable-syslog option. changed all callers from TPRINTF to elog(DEBUG)
2000-05-31 02:28:42 +02:00
Revert "Add USER SET parameter values for pg_db_role_setting" This reverts commit 096dd80f3ccc and its fixups beecbe8e5001, afdd9f7f0e00, 529da086ba, db93e739ac61. Catversion is bumped. Discussion: https://postgr.es/m/d46f9265-ff3c-6743-2278-6772598233c2%40pgmasters.net
2023-05-17 19:06:50 +02:00
extern void ProcessGUCArray(ArrayType *array,
Arrange for SET LOCAL's effects to persist until the end of the current top transaction, unless rolled back or overridden by a SET clause for the same variable attached to a surrounding function call. Per discussion, these seem the best semantics. Note that this is an INCOMPATIBLE CHANGE: in 8.0 through 8.2, SET LOCAL's effects disappeared at subtransaction commit (leading to behavior that made little sense at the SQL level). I took advantage of the opportunity to rewrite and simplify the GUC variable save/restore logic a little bit. The old idea of a "tentative" value is gone; it was a hangover from before we had a stack. Also, we no longer need a stack entry for every nesting level, but only for those in which a variable's value actually changed.
2007-09-11 02:06:42 +02:00
GucContext context, GucSource source, GucAction action);
Revert "Add USER SET parameter values for pg_db_role_setting" This reverts commit 096dd80f3ccc and its fixups beecbe8e5001, afdd9f7f0e00, 529da086ba, db93e739ac61. Catversion is bumped. Discussion: https://postgr.es/m/d46f9265-ff3c-6743-2278-6772598233c2%40pgmasters.net
2023-05-17 19:06:50 +02:00
extern ArrayType *GUCArrayAdd(ArrayType *array, const char *name, const char *value);
extern ArrayType *GUCArrayDelete(ArrayType *array, const char *name);
extern ArrayType *GUCArrayReset(ArrayType *array);
The heralded `Grand Unified Configuration scheme' (GUC) That means you can now set your options in either or all of $PGDATA/configuration, some postmaster option (--enable-fsync=off), or set a SET command. The list of options is in backend/utils/misc/guc.c, documentation will be written post haste. pg_options is gone, so is that pq_geqo config file. Also removed were backend -K, -Q, and -T options (no longer applicable, although -d0 does the same as -Q). Added to configure an --enable-syslog option. changed all callers from TPRINTF to elog(DEBUG)
2000-05-31 02:28:42 +02:00
Split up guc.c for better build speed and ease of maintenance. guc.c has grown to be one of our largest .c files, making it a bottleneck for compilation. It's also acquired a bunch of knowledge that'd be better kept elsewhere, because of our not very good habit of putting variable-specific check hooks here. Hence, split it up along these lines: * guc.c itself retains just the core GUC housekeeping mechanisms. * New file guc_funcs.c contains the SET/SHOW interfaces and some SQL-accessible functions for GUC manipulation. * New file guc_tables.c contains the data arrays that define the built-in GUC variables, along with some already-exported constant tables. * GUC check/assign/show hook functions are moved to the variable's home module, whenever that's clearly identifiable. A few hard- to-classify hooks ended up in commands/variable.c, which was already a home for miscellaneous GUC hook functions. To avoid cluttering a lot more header files with #include "guc.h", I also invented a new header file utils/guc_hooks.h and put all the GUC hook functions' declarations there, regardless of their originating module. That allowed removal of #include "guc.h" from some existing headers. The fallout from that (hopefully all caught here) demonstrates clearly why such inclusions are best minimized: there are a lot of files that, for example, were getting array.h at two or more levels of remove, despite not having any connection at all to GUCs in themselves. There is some very minor code beautification here, such as renaming a couple of inconsistently-named hook functions and improving some comments. But mostly this just moves code from point A to point B and deals with the ensuing needs for #include adjustments and exporting a few functions that previously weren't exported. Patch by me, per a suggestion from Andres Freund; thanks also to Michael Paquier for the idea to invent guc_funcs.c. Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
extern void *guc_malloc(int elevel, size_t size);
extern pg_nodiscard void *guc_realloc(int elevel, void *old, size_t size);
extern char *guc_strdup(int elevel, const char *src);
Store GUC data in a memory context, instead of using malloc(). The only real argument for using malloc directly was that we needed the ability to not throw error on OOM; but mcxt.c grew that feature awhile ago. Keeping the data in a memory context improves accountability and debuggability --- for example, without this it's almost impossible to detect memory leaks in the GUC code with anything less costly than valgrind. Moreover, the next patch in this series will add a hash table for GUC lookup, and it'd be pretty silly to be using palloc-dependent hash facilities alongside malloc'd storage of the underlying data. This is a bit invasive though, in particular causing an API break for GUC check hooks that want to modify the GUC's value or use an "extra" data structure. They must now use guc_malloc() and guc_free() instead of malloc() and free(). Failure to change affected code will result in assertion failures or worse; but thanks to recent effort in the mcxt infrastructure, it shouldn't be too hard to diagnose such oversights (at least in assert-enabled builds). One note is that this changes ParseLongOption() to return short-lived palloc'd not malloc'd data. There wasn't any caller for which the previous definition was better. Discussion: https://postgr.es/m/2982579.1662416866@sss.pgh.pa.us
2022-10-14 18:10:48 +02:00
extern void guc_free(void *ptr);
Split up guc.c for better build speed and ease of maintenance. guc.c has grown to be one of our largest .c files, making it a bottleneck for compilation. It's also acquired a bunch of knowledge that'd be better kept elsewhere, because of our not very good habit of putting variable-specific check hooks here. Hence, split it up along these lines: * guc.c itself retains just the core GUC housekeeping mechanisms. * New file guc_funcs.c contains the SET/SHOW interfaces and some SQL-accessible functions for GUC manipulation. * New file guc_tables.c contains the data arrays that define the built-in GUC variables, along with some already-exported constant tables. * GUC check/assign/show hook functions are moved to the variable's home module, whenever that's clearly identifiable. A few hard- to-classify hooks ended up in commands/variable.c, which was already a home for miscellaneous GUC hook functions. To avoid cluttering a lot more header files with #include "guc.h", I also invented a new header file utils/guc_hooks.h and put all the GUC hook functions' declarations there, regardless of their originating module. That allowed removal of #include "guc.h" from some existing headers. The fallout from that (hopefully all caught here) demonstrates clearly why such inclusions are best minimized: there are a lot of files that, for example, were getting array.h at two or more levels of remove, despite not having any connection at all to GUCs in themselves. There is some very minor code beautification here, such as renaming a couple of inconsistently-named hook functions and improving some comments. But mostly this just moves code from point A to point B and deals with the ensuing needs for #include adjustments and exporting a few functions that previously weren't exported. Patch by me, per a suggestion from Andres Freund; thanks also to Michael Paquier for the idea to invent guc_funcs.c. Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
SECOND ATTEMPT Dump/read non-default GUC values for use by exec'ed backend, for Win32.
2003-05-03 00:02:47 +02:00
#ifdef EXEC_BACKEND
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
extern void write_nondefault_variables(GucContext context);
extern void read_nondefault_variables(void);
SECOND ATTEMPT Dump/read non-default GUC values for use by exec'ed backend, for Win32.
2003-05-03 00:02:47 +02:00
#endif
Add infrastructure to save and restore GUC values. This is further infrastructure for parallelism. Amit Khandekar, Noah Misch, Robert Haas
2014-11-24 22:13:11 +01:00
/* GUC serialization */
extern Size EstimateGUCStateSpace(void);
extern void SerializeGUCState(Size maxsize, char *start_address);
extern void RestoreGUCState(void *gucstate);
Split up guc.c for better build speed and ease of maintenance. guc.c has grown to be one of our largest .c files, making it a bottleneck for compilation. It's also acquired a bunch of knowledge that'd be better kept elsewhere, because of our not very good habit of putting variable-specific check hooks here. Hence, split it up along these lines: * guc.c itself retains just the core GUC housekeeping mechanisms. * New file guc_funcs.c contains the SET/SHOW interfaces and some SQL-accessible functions for GUC manipulation. * New file guc_tables.c contains the data arrays that define the built-in GUC variables, along with some already-exported constant tables. * GUC check/assign/show hook functions are moved to the variable's home module, whenever that's clearly identifiable. A few hard- to-classify hooks ended up in commands/variable.c, which was already a home for miscellaneous GUC hook functions. To avoid cluttering a lot more header files with #include "guc.h", I also invented a new header file utils/guc_hooks.h and put all the GUC hook functions' declarations there, regardless of their originating module. That allowed removal of #include "guc.h" from some existing headers. The fallout from that (hopefully all caught here) demonstrates clearly why such inclusions are best minimized: there are a lot of files that, for example, were getting array.h at two or more levels of remove, despite not having any connection at all to GUCs in themselves. There is some very minor code beautification here, such as renaming a couple of inconsistently-named hook functions and improving some comments. But mostly this just moves code from point A to point B and deals with the ensuing needs for #include adjustments and exporting a few functions that previously weren't exported. Patch by me, per a suggestion from Andres Freund; thanks also to Michael Paquier for the idea to invent guc_funcs.c. Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
2022-09-13 17:05:07 +02:00
/* Functions exported by guc_funcs.c */
extern void ExecSetVariableStmt(VariableSetStmt *stmt, bool isTopLevel);
extern char *ExtractSetVariableArgs(VariableSetStmt *stmt);
extern void SetPGVariable(const char *name, List *args, bool is_local);
extern void GetPGVariable(const char *name, DestReceiver *dest);
extern TupleDesc GetPGVariableResultDesc(const char *name);
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
/* Support for messages reported from GUC check hooks */
extern PGDLLIMPORT char *GUC_check_errmsg_string;
extern PGDLLIMPORT char *GUC_check_errdetail_string;
extern PGDLLIMPORT char *GUC_check_errhint_string;
extern void GUC_check_errcode(int sqlerrcode);
#define GUC_check_errmsg \
pre_format_elog_string(errno, TEXTDOMAIN), \
GUC_check_errmsg_string = format_elog_string
#define GUC_check_errdetail \
pre_format_elog_string(errno, TEXTDOMAIN), \
GUC_check_errdetail_string = format_elog_string
#define GUC_check_errhint \
pre_format_elog_string(errno, TEXTDOMAIN), \
GUC_check_errhint_string = format_elog_string
The heralded `Grand Unified Configuration scheme' (GUC) That means you can now set your options in either or all of $PGDATA/configuration, some postmaster option (--enable-fsync=off), or set a SET command. The list of options is in backend/utils/misc/guc.c, documentation will be written post haste. pg_options is gone, so is that pq_geqo config file. Also removed were backend -K, -Q, and -T options (no longer applicable, although -d0 does the same as -Q). Added to configure an --enable-syslog option. changed all callers from TPRINTF to elog(DEBUG)
2000-05-31 02:28:42 +02:00
#endif /* GUC_H */