天天看點

pg參數歸類說明This is a comment

在http://blog.163.com/donfang_jianping/blog/static/13647395120155299412856/中,我們介紹了PostgreSQL在Linux上的安裝,這裡我們來看一下PostgreSQL有那些初始化參數。

這個是摘抄的别人的,寫個人說明,這個就是讓你來看看都有哪些類型的參數,等你以後想修改或者使用的時候就可以心中有數,檢視這些參數及設定應該是用show \set \pset select 參數 比如show all ;至于哪些用\pset 哪些用\set 哪些用show檢視 哪些用select檢視,有知道的可以@我,發給我,

x先看看英文的

19.1. Setting Parameters

19.1.1. Parameter Names and Values

All parameter names are case-insensitive. Every parameter takes a value of one of five types: boolean, string, integer, floating point, or enumerated (enum). The type determines the syntax for setting the parameter:

Boolean: Values can be written as on, off, true, false, yes, no, 1, 0 (all case-insensitive) or any unambiguous prefix of one of these.

String: In general, enclose the value in single quotes, doubling any single quotes within the value. Quotes can usually be omitted if the value is a simple number or identifier, however.

Numeric (integer and floating point): A decimal point is permitted only for floating-point parameters. Do not use thousands separators. Quotes are not required.

Numeric with Unit: Some numeric parameters have an implicit unit, because they describe quantities of memory or time. The unit might be kilobytes, blocks (typically eight kilobytes), milliseconds, seconds, or minutes. An unadorned numeric value for one of these settings will use the setting's default unit, which can be learned from pg_settings.unit. For convenience, settings can be given with a unit specified explicitly, for example '120 ms' for a time value, and they will be converted to whatever the parameter's actual unit is. Note that the value must be written as a string (with quotes) to use this feature. The unit name is case-sensitive, and there can be whitespace between the numeric value and the unit.

Valid memory units are kB (kilobytes), MB (megabytes), GB (gigabytes), and TB (terabytes). The multiplier for memory units is 1024, not 1000.

Valid time units are ms (milliseconds), s (seconds), min (minutes), h (hours), and d (days).

Enumerated: Enumerated-type parameters are written in the same way as string parameters, but are restricted to have one of a limited set of values. The values allowable for such a parameter can be found from pg_settings.enumvals. Enum parameter values are case-insensitive.

19.1.2. Parameter Interaction via the Configuration File

The most fundamental way to set these parameters is to edit the file postgresql.conf, which is normally kept in the data directory. A default copy is installed when the database cluster directory is initialized. An example of what this file might look like is:

log_connections = yes

log_destination = 'syslog'

search_path = '"$user", public'

shared_buffers = 128MB

One parameter is specified per line. The equal sign between name and value is optional. Whitespace is insignificant (except within a quoted parameter value) and blank lines are ignored. Hash marks (#) designate the remainder of the line as a comment. Parameter values that are not simple identifiers or numbers must be single-quoted. To embed a single quote in a parameter value, write either two quotes (preferred) or backslash-quote.

Parameters set in this way provide default values for the cluster. The settings seen by active sessions will be these values unless they are overridden. The following sections describe ways in which the administrator or user can override these defaults.

The configuration file is reread whenever the main server process receives a SIGHUP signal; this signal is most easily sent by running pg_ctl reload from the command line or by calling the SQL function pg_reload_conf(). The main server process also propagates this signal to all currently running server processes, so that existing sessions also adopt the new values (this will happen after they complete any currently-executing client command). Alternatively, you can send the signal to a single server process directly. Some parameters can only be set at server start; any changes to their entries in the configuration file will be ignored until the server is restarted. Invalid parameter settings in the configuration file are likewise ignored (but logged) during SIGHUP processing.

In addition to postgresql.conf, a PostgreSQL data directory contains a file postgresql.auto.conf, which has the same format as postgresql.conf but should never be edited manually. This file holds settings provided through the ALTER SYSTEM command. This file is automatically read whenever postgresql.conf is, and its settings take effect in the same way. Settings in postgresql.auto.conf override those in postgresql.conf.

The system view pg_file_settings can be helpful for pre-testing changes to the configuration file, or for diagnosing problems if a SIGHUP signal did not have the desired effects.

19.1.3. Parameter Interaction via SQL

PostgreSQL provides three SQL commands to establish configuration defaults. The already-mentioned ALTER SYSTEM command provides a SQL-accessible means of changing global defaults; it is functionally equivalent to editing postgresql.conf. In addition, there are two commands that allow setting of defaults on a per-database or per-role basis:

The ALTER DATABASE command allows global settings to be overridden on a per-database basis.

The ALTER ROLE command allows both global and per-database settings to be overridden with user-specific values.

Values set with ALTER DATABASE and ALTER ROLE are applied only when starting a fresh database session. They override values obtained from the configuration files or server command line, and constitute defaults for the rest of the session. Note that some settings cannot be changed after server start, and so cannot be set with these commands (or the ones listed below).

Once a client is connected to the database, PostgreSQL provides two additional SQL commands (and equivalent functions) to interact with session-local configuration settings:

The SHOW command allows inspection of the current value of all parameters. The corresponding function is current_setting(setting_name text).

The SET command allows modification of the current value of those parameters that can be set locally to a session; it has no effect on other sessions. The corresponding function is set_config(setting_name, new_value, is_local).

In addition, the system view pg_settings can be used to view and change session-local values:

Querying this view is similar to using SHOW ALL but provides more detail. It is also more flexible, since it's possible to specify filter conditions or join against other relations.

Using UPDATE on this view, specifically updating the setting column, is the equivalent of issuing SET commands. For example, the equivalent of

SET configuration_parameter TO DEFAULT;

is:

UPDATE pg_settings SET setting = reset_val WHERE name = 'configuration_parameter';

另外就是配置檔案postgresql.conf 這個裡邊可以加載多個參數檔案用include_dir '配置檔案的目錄名' 然後将配置檔案放到此目錄下,或者include '配置檔案'

在PostgreSQL當中,我們也可以通過查詢資料庫字典pg_settings來檢視目前參數的一些配置。該資料字典類似于Oracle裡面的v$parameter或是x$ksppi,x$ksppcv。

下面,我們來看一下pg_settings這個資料字典。

[pgsqladmin@pgsql ~]$ psql -d postgres

psql (9.4.4)

Type "help" for help.

postgres=# \d pg_settings

View "pg_catalog.pg_settings"

Column | Type | Modifiers 

------------+---------+-----------

name | text | 

setting | text | 

unit | text | 

category | text | 

short_desc | text | 

extra_desc | text | 

context | text | 

vartype | text | 

source | text | 

min_val | text | 

max_val | text | 

enumvals | text[] | 

boot_val | text | 

reset_val | text | 

sourcefile | text | 

sourceline | integer |

postgres=# 

它有這麼多列。

backend

user

internal

postmaster

superuser

sighup

(6 rows)

下面,我們來看一下這些類型的具體表示意義,

user:該類參數表示,普通使用者可以通過set指令來更改參數的配置值。

internal:該類參數是内部參數,也就是說,不可以進行修改。不同于Oracle裡面的隐含參數,隐含參數我們是可以修改的。

postmaster:該類參數更改配置項後,需要重新開機PostgreSQL執行個體才能生效。類似于Oracle裡面的靜态參數。

superuser:該類參數可以由超級使用者來改變,改變時,隻會影響到自身的session,不會影響到其他的使用者。類似于Oracle裡面的alter session set parameter = value或是alter session set parameter = value與alter system set parameter = value scope=spfile的結合。

sighup:在postgresql.conf配置檔案中更改這種類型的參數無須重新開機執行個體,隻需要向postmaster程序發送一個SIGHUP信号,讓其重新讀取配置檔案即可。postmaster程序收到信号後,也會向其他子程序發送SIGHUP信号,讓新的參數值在其他子程序中也生效。該類參數差別于backend類參數。

對于PostgreSQL參數,我把歸為如下幾類:

(1)與連接配接相關的參數。

listen_addresses:用來指定伺服器監聽TCP/IP位址,改變該參數時,需要重新開機資料庫服務。如果存在多個IP,我們在配置的時候,使用逗号進行分隔。預設為localhost,表示隻允許本地進行連接配接。我們也可以配置為“*”或是“0.0.0.0”,表示監聽本機上的所有IP。具體更精通的網絡控制的配置,是由配置檔案pg_hba.conf配置檔案來完成的(該配置檔案類似于Oracle裡的sqlnet.ora),在後續,我會再介紹該配置檔案。

port:用來指定監聽的端口,預設為5432,改變後,需要重新開機資料庫服務。

max_connections:指定資料庫允許的最大并發連接配接數,改變該參數需要重新開機資料庫服務。該參數類似于Oracle裡面的processes,sessions。

superuser_reserved_connections:指定PostgreSQL超級使用者預保留的連接配接數,預設為3,改變後需要重新開機資料庫服務。配置該參數的目的是防止普通使用者把連接配接數占用完而超級使用者連接配接不上。

unix_socket_directory:指定伺服器監聽用戶端連接配接的unix套接字目錄,該參數隻能在編譯的時候修改,預設為/tmp。

unix_socket_group:設定unix域套接字所屬的組(套接字所屬使用者總是啟動伺服器的使用者),改變該參數需要重新開機資料庫服務。

unix_scoket_permissions:設定unix域套接字的通路權限,預設為0777,改變該參數需要重新開機資料庫服務。

tcp_keepalives_idle:表示在一個TCP連接配接當中空閑多長時間後會發送一個keepalive封包,預設為0,表示使用作業系統設定的預設值。

tcp_keepalives_count:表示在一個空間的TCP連接配接上,發送keepalive封包後,如果一直沒有收到回應,最多發送多少次後,就認為該連接配接已經中斷了。

tcp_keepalives_interval:表示如果在發送一個keepalive包後,如果沒有收到回應,再間隔多長時間發送一個。

與記憶體相關的配置項:

shared_buffers;該參數用來指定資料庫伺服器使用的共享記憶體的數量。一般情況下,設定為實體記憶體的25%。

該參數的值必須大于16,并且至少是max_connections數值的兩倍。

temp_buffers:設定每個資料庫會話使用臨時緩沖區的最大數目,此記憶體結果隻用于緩沖臨時表的資料。

work_mem:用來指定一些排序或是散列操作所使用記憶體數目,如果所進行的操作超過了目前設定的大小,那麼它會使用臨時磁盤檔案。

maintenance_work_mem:指定在進行維護性操作(比如create index,vacuum等)時所使用的最大記憶體量。

max_stack_depth:用來指定伺服器執行堆棧的最大安全深度,預設為2M,如果發現不能運作複雜的函數,可以适當地提高此參數的值。

關于WAL日志一些參數:

wal_level:指定生成wal日志的級别,值為minmal,archive,hot_standby。minmal一般的配置,archive會生成wal歸檔需要的日志記錄,hot_standby添加備庫時需要設定。 

fsync:表示是否使用fsync()系統調用把檔案系統中的髒頁重新整理到實體磁盤,確定資料庫在崩潰的情況下可以恢複到崩潰前的狀态,該值預設為true。

synchronous_commit:表示送出一個事務後,是否需要等待把wal日志寫到磁盤後再傳回,預設為true。

wal_sync_method:用來指定向磁盤強制更新wal日志的方法,一般采用預設值就OK。

full_page_writes:值為true或false,如果打開該選項時,PostgreSQL伺服器會在檢查點之後對頁面第一次修改時将整個頁面寫到wal日志。

wal_buffers:用來指定在共享記憶體裡用于存儲wal日志的緩沖區數目,預設為8,即可64K,通常此參數設定為8——128(即64K到1M)就可以了。

wal_writer_delay:指定wal writer process把wal日志寫入到磁盤的周期,預設為200毫秒。

commit_delay:用來指定向wal緩沖區寫入記錄和将緩沖區重新整理到磁盤之間的時間延遲,預設0,表示沒有延遲,機關為微秒。

commit_siblings:在執行commit_delay延遲時,要求同時打開的最少并發事務數,預設為5。

關于錯誤日志的一些參數:

logging_collector = on,表示打開日志搜集。

log_rotation_age:表示日志超過多長時間就生成一個新的日志檔案。

log_rotation_size:表示日志超過多大的時候就會生成一個新的日志檔案。

log_filename:指定日志檔案名,比如logfilename = 'postgresql-%Y-%m-%d%u.log'。

log_directory:用來指定日志檔案生成的目錄。

另外,還有如下一些日志參數也可能會用到:

debug_print_parse:設定為on時,把SQL的解析樹輸出到日志中。

debug_print_rewritten:設定為on時,把SQL的查詢重寫列印到日志中。

debug_print_plan:設定為on時,把SQL的執行計劃列印輸出到日志中。

debug_pretty_print:美化上述的三種輸出,使其更容易閱讀。

log_checkpoint:是否記錄checkpoint。

log_connections:是否記錄用戶端的連接配接。

log_disconnections:是否記錄用戶端斷開的連接配接。

log_duration:是否記錄每個已完成語句的持續時間。

log_hostname:是否記錄用戶端的主機名。

log_lock_waits:當一個會話的等待時間超過deadlock_timeout時,是否記錄一條日志到日志檔案中。

本文轉自 aklaus 51CTO部落格,原文連結:http://blog.51cto.com/aklaus/2059706