postgresql中增加系统参数

 

/* * Certain options can only be set at certain times. The rules are * like this: * * 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. * * 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 * 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.) * * 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).  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. * * SUSET options can be set at postmaster startup, with the SIGHUP * mechanism, or from SQL if you're a superuser. * * USERSET options can be set by anyone any time. */typedef enum{PGC_INTERNAL,PGC_POSTMASTER,PGC_SIGHUP,PGC_BACKEND,PGC_SUSET,PGC_USERSET} GucContext;/* * 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 * 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 * as the current value.  Note that source == PGC_S_OVERRIDE should be * used when setting a PGC_INTERNAL option. * * PGC_S_INTERACTIVE isn't actually a source value, but is the * dividing line between "interactive" and "non-interactive" sources for * error reporting purposes. * * PGC_S_TEST is used when testing values to be stored as per-database or * per-user defaults ("doit" will always be false, so this never gets stored * as the actual source of any value).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. * * NB: see GucSource_Names in guc.c if you change this. */typedef enum{PGC_S_DEFAULT,/* hard-wired default ("boot_val") */PGC_S_DYNAMIC_DEFAULT,/* default computed during initialization */PGC_S_ENV_VAR,/* postmaster environment variable */PGC_S_FILE,/* postgresql.conf */PGC_S_ARGV,/* postmaster command line */PGC_S_DATABASE,/* per-database setting */PGC_S_USER,/* per-user setting */PGC_S_DATABASE_USER,/* per-user-and-database setting */PGC_S_CLIENT,/* from client connection request */PGC_S_OVERRIDE,/* special case to forcibly set default */PGC_S_INTERACTIVE,/* dividing line for error reporting */PGC_S_TEST,/* test per-database or per-user setting */PGC_S_SESSION/* SET command */} GucSource;

/*
 
Per-Variable Hooks------------------
Each variable known to GUC can optionally have a check_hook, anassign_hook, and/or a show_hook to provide customized behavior.Check hooks are used to perform validity checking on variable values(above and beyond what GUC can do), to compute derived settings whennontrivial work is needed to do that, and optionally to "canonicalize"user-supplied values.  Assign hooks are used to update any derived statethat needs to change when a GUC variable is set.  Show hooks are used tomodify the default SHOW display for a variable.
If a check_hook is provided, it points to a function of the signature bool check_hook(datatype *newvalue, void **extra, GucSource source)The "newvalue" argument is of type bool *, int *, double *, or char **for bool, int/enum, real, or string variables respectively.  The checkfunction should validate the proposed new value, and return true if it isOK or false if not.  The function can optionally do a few other things:
* When rejecting a bad proposed value, it may be useful to append someadditional information to the generic "invalid value for parameter FOO"complaint that guc.c will emit.  To do that, call void GUC_check_errdetail(const char *format, ...)where the format string and additional arguments follow the rules forerrdetail() arguments.  The resulting string will be emitted as theDETAIL line of guc.c's error report, so it should follow the message styleguidelines for DETAIL messages.  There is also void GUC_check_errhint(const char *format, ...)which can be used in the same way to append a HINT message.Occasionally it may even be appropriate to override guc.c's generic primarymessage or error code, which can be done with void GUC_check_errcode(int sqlerrcode) void GUC_check_errmsg(const char *format, ...)In general, check_hooks should avoid throwing errors directly if possible,though this may be impractical to avoid for some corner cases such asout-of-memory.
* Since the newvalue is pass-by-reference, the function can modify it.This might be used for example to canonicalize the spelling of a stringvalue, round off a buffer size to the nearest supported value, or replacea special value such as "-1" with a computed default value.  If thefunction wishes to replace a string value, it must malloc (not palloc)the replacement value, and be sure to free() the previous value.
* Derived information, such as the role OID represented by a user name,can be stored for use by the assign hook.  To do this, malloc (not palloc)storage space for the information, and return its address at *extra.guc.c will automatically free() this space when the associated GUC settingis no longer of interest.  *extra is initialized to NULL before call, soit can be ignored if not needed.
The "source" argument indicates the source of the proposed new value,If it is >= PGC_S_INTERACTIVE, then we are performing an interactiveassignment (e.g., a SET command).  But when source < PGC_S_INTERACTIVE,we are reading a non-interactive option source, such as postgresql.conf.This is sometimes needed to determine whether a setting should beallowed.  The check_hook might also look at the current actual value ofthe variable to determine what is allowed.
Note that check hooks are sometimes called just to validate a value,without any intention of actually changing the setting.  Therefore thecheck hook must *not* take any action based on the assumption that anassignment will occur.
If an assign_hook is provided, it points to a function of the signature void assign_hook(datatype newvalue, void *extra)where the type of "newvalue" matches the kind of variable, and "extra"is the derived-information pointer returned by the check_hook (alwaysNULL if there is no check_hook).  This function is called immediatelybefore actually setting the variable's value (so it can look at the actualvariable to determine the old value, for example to avoid doing work whenthe value isn't really changing).
Note that there is no provision for a failure result code.  assign_hooksshould never fail except under the most dire circumstances, since a failuremay for example result in GUC settings not being rolled back properly duringtransaction abort.  In general, try to do anything that could conceivablyfail in a check_hook instead, and pass along the results in an "extra"struct, so that the assign hook has little to do beyond copying the data tosomeplace.  This applies particularly to catalog lookups: any requiredlookups must be done in the check_hook, since the assign_hook may beexecuted during transaction rollback when lookups will be unsafe.
Note that check_hooks are sometimes called outside any transaction, too.This happens when processing the wired-in "bootstrap" value, values comingfrom the postmaster command line or environment, or values coming frompostgresql.conf.  Therefore, any catalog lookups done in a check_hookshould be guarded with an IsTransactionState() test, and there must be afallback path to allow derived values to be computed during the firstsubsequent use of the GUC setting within a transaction.  A typicalarrangement is for the catalog values computed by the check_hook andinstalled by the assign_hook to be used only for the remainder of thetransaction in which the new setting is made.  Each subsequent transactionlooks up the values afresh on first use.  This arrangement is useful toprevent use of stale catalog values, independently of the problem ofneeding to check GUC values outside a transaction.
If a show_hook is provided, it points to a function of the signature const char *show_hook(void)This hook allows variable-specific computation of the value displayedby SHOW (and other SQL features for showing GUC variable values).The return value can point to a static buffer, since show functions arenot used re-entrantly.
*/

/* * Contents of GUC tables * * See src/backend/utils/misc/README for design notes. * * TO ADD AN OPTION: * * 1. Declare a global variable of type bool, int, double, or char* *   and make use of it. * * 2. Decide at what times it's safe to set the option. See guc.h for *   details. * * 3. Decide on a name, a default value, upper and lower bounds (if *   applicable), etc. * * 4. Add a record below. * * 5. Add it to src/backend/utils/misc/postgresql.conf.sample, if *   appropriate. * * 6. Don't forget to document the option (at least in config.sgml). * * 7. If it's a new GUC_LIST option you must edit pg_dumpall.c to ensure *   it is not single quoted at dump time. *//*要增加参数的话，在需要的c文件增加定义，在对应的h文件 xtern PGDLLIMPORT 增加声明，在 /src/backend/utils/misc/guc.c 根据参数不同的数据类型，去不同的数组里面增加，之后就可以在postgre.conf里面指定值了，这是最简单的方法，pg是多进程的，在一个进程中指定参数值，是没有改变全局值的，改变全局值需要给主进程发信号，主进程重新读postgre.conf*/