5.16. Misc Configuration Parameters

Specifies the relation cache expiration time in seconds. The relation cache is used for caching the query result of PostgreSQL system catalogs that is used by Pgpool-II to get various information including the table structures and to check table types(e.g. To check if the referred table is a temporary table or not). The cache is maintained in the local memory space of Pgpool-II child process and its lifetime is same as of the child process. The cache is also maintained in shared memory to share among child processes,if enable enable_shared_relcache. So If the table is modified using ALTER TABLE or some other means, the relcache becomes inconsistent. For this purpose, relcache_expire controls the life time of the cache. Default is 0, which means the cache never expires.

This parameter can only be set at server start.

Specifies the number of relcache entries. Default is 256. The cache is created about 10 entries per table. So you can estimate the required number of relation cache at "number of using table * 10".

This parameter can only be set at server start.

By setting to on, relation cache is shared among Pgpool-II child processes using the in memory query cache (see Section 5.13.1 for more details). Default is on. Each child process needs to access to the system catalog from PostgreSQL. By enabling this feature, other process can extract the catalog lookup result from the query cache and it should reduce the frequency of the query. Cache invalidation is not happen even if the system catalog is modified. So it is strongly recommend to set time out base cache invalidation by using relcache_expire parameter.

This parameter can be used even if memory_cache_enabled is off. In this case some query cache parameters(memqcache_method, memqcache_maxcache and each cache storage parameter) is used together.

Pgpool-II search the local relation cache first. If it is not found on the cache, the shared relation query cache is searched if this feature is enabled. If it is found on query cache, it is copied into the local relation cache. If a cache entry is not found on anywhere, Pgpool-II executes the query against PostgreSQL, and the result is stored into the shared relation cache and the local cache.

This parameter can only be set at server start.

The target node to send queries to create relation cache entries. If set to primary, queries will be sent to primary node. This is the default and recommended to most users because the query could get the latest information. If you want to lower the load of primary node, you can set the parameter to load_balance_node, which will send queries to the load balance node. This is especially useful for such a system where Pgpool-II/primary server is on a continent A while other Pgpool-II/standby server is on other continent B. Clients on B want read data from the standby because it's much geographically closer. In this case you can set backend_weight0 (this represents primary) to 0, backend_weight1 to 1 (this represents standby) and set relcache_query_target to load_balance_node.

Note, however, if you send query to the standby node, recently created tables and rows might not be available on the standby server yet because of replication delay. Thus such a configuration is not recommended for systems where data modification activity is high.

This parameter can be changed by reloading the Pgpool-II configurations.

Setting to catalog or trace, enables the temporary table check in the SELECT statements. To check the temporary table Pgpool-II queries the system catalog of primary/main PostgreSQL backend if catalog is specified, which increases the load on the primary/main server.

If trace is set, Pgpool-II traces temporary table creation and dropping to obtain temporary table info. So no need to access system catalogs. However, if temporary table creation is invisible to Pgpool-II (done in functions or triggers, for example), Pgpool-II cannot recognize the creation of temporary tables.

If you are absolutely sure that your system never uses temporary tables, then you can safely set to none.

Default is catalog.

This parameter can be changed by reloading the Pgpool-II configurations. You can also use PGPOOL SET command to alter the value of this parameter for a current session.

Setting to on, enables the unlogged table check in the SELECT statements. To check the unlogged table Pgpool-II queries the system catalog of primary/main PostgreSQL backend which increases the load on the primary/main server. If you are absolutely sure that your system never uses the unlogged tables (for example, you are using 9.0 or earlier version of PostgreSQL) then you can safely turn off the check_unlogged_table. Default is on.

This parameter can be changed by reloading the Pgpool-II configurations. You can also use PGPOOL SET command to alter the value of this parameter for a current session.

Specifies the full path to a file to store the Pgpool-II process id. The pid_file_name path can be specified as relative to the location of pgpool.conf file or as an absolute path Default is "/var/run/pgpool/pgpool.pid".

This parameter can only be set at server start.

Specifies the full path to a directory to store the pgpool_status. Default is '/tmp'.

This parameter can only be set at server start.

Setting to on, enables the testing facility of health checking. In this case the health check process looks into backend_down_request under logdir. The file may contain multiple lines, and each line corresponds to each backend. A line in the file starts with backend id (must be a decimal number starting with zero), then a TAB, and ends with "down". The backend is assumed in down status and Pgpool-II will start a failover. Once the failover completes, the "down" is rewritten to "already_down" by health check process to prevent repeating failovers.

This feature is particularly useful for testing failover_require_consensus. Suppose we have 3 watchdog node. Each watchdog checks healthiness of backend 0. By setting "0 down" in the file only under watchdog 0, other watchdogs disagree with the unhealthiness of backend 0, so failover will not occur. This kind of partial network failure can be simulated using this feature.

Default is off.

This parameter can only be set at server start.