711
京東網上商城
PostgreSQL服務器管理：服務器配置
本文檔為PostgreSQL 9.6.0文檔，本轉載已得到原譯者彭煜瑋授權。
1.1. 參數名稱和值
所有參數名都是大小寫不敏感的。每個參數都可以接受五種類型之一的值： 布爾、字符串、整數、 浮點數或枚舉。該類型決定了設置該參數的語法：
- 布爾: 值可以被寫成 on, off, true, false, yes, no, 1, 0 （都是大小寫不敏感的）或者這些值的任何無歧義前綴。
- 字符串: 通常值被包括在單引號內，值內部的任何單引號都需要被雙寫。不過，如果值是一個簡單數字或者 標識符，引號通常可以被省略。
- 數字（整數和浮點）: 隻對浮點參數允許一個小數點。不要使用千位分隔符。不要求引號。
- 帶單位的數字: 一些數字參數具有隱含單位，因為它們描述內存或時間量。單位可能是千字節、塊（通常是 8KB）、 毫秒、秒或分鍾。這些設置之一的一個未修飾的數字值將使用該設置的默認單位，默認單位可以通 過引用pg_settings.unit來找到。為了方便，也可以 顯式地指定一個不同的單位，例如時間值可以是'120 ms'，並且它們將被轉換到參數的實際單位。要使用這個特性，注意值必須被寫成一個字符 串（帶有引號）。單位名稱是大小寫敏感的，並且在數字值和單位之間可以有空白。
- 可用的內存單位是kB（千字節）、MB（兆字節）和GB（吉字節）。內存單位的乘數是 1024 而不是 1000。
- 可用的時間單位是ms（毫秒）、s（秒）、min（分鍾）、 h（小時）和d（天）。
- 枚舉: 枚舉類型的參數以與字符串參數相同的方式指定，但被限製到一組有限的值。 這樣一個參數可用的值可以在pg_settings.enumvals 中找到。枚舉參數值是大小寫無關的。
1.2. 通過配置文件影響參數
設置這些參數最基本的方法是編輯postgresql.conf文件， 它通常被保存在數據目錄中（當數據庫集簇目錄被初始化時，一個默認的拷貝將會被安裝在那裏）。一個該文件的例子看起來是：
# This is a comment
log_connections = yes
log_destination = 'syslog'
search_path = '"$user", public'
shared_buffers = 128MB
每一行指定一個參數。名稱和值之間的等號是可選的。空白是無意義的（除了在一個引號引用的參數值內）並且空行被忽略。井號（#）指示該行的剩餘部分是一個注釋。非簡單標識符或者數字的參數值必須用單引號包圍。要在參數值裏嵌入單引號， 要麼寫兩個單引號（首選）或者在引號前放反斜線。
以這種方式設定的參數為集簇提供了默認值。除非這些設置被覆蓋，活動會話看到的就是這些設置。 下麵的小節描述了管理員或用戶覆蓋這些默認值的方法。
主服務器進程每次收到SIGHUP信號（最簡單的方法是從命令行運行pg_ctl reload或調用 SQL 函數pg_reload_conf()來發送這個信號）後都會重新讀取這個配置 文件。主服務器進程還會把這個信號傳播給所有正在運行的服務器進程，這樣現有的會話也能采用新 值（要等待它們完成當前正在執行的客戶端命令之後才會發生）。另外，你可以直接向一個單一服務 器進程發送該信號。有些參數隻能在服務器啟動時設置，在配置文件中對這些條目的修改將被忽略， 直到下次服務器重啟。配置文件中的非法參數設置也會在SIGHUP處理過程中被 忽略（但是會記錄日誌）。
1.3. 通過SQL影響參數
PostgreSQL提供了三個SQL命令來建立配置默認值。 已經提到過的ALTER SYSTEM命令提供了一種改變全局默認值的從SQL可 訪問的方法；它在功效上等效於編輯postgresql.conf。此外，還有兩個命令 可以針對每個數據庫或者每個角色設置默認值：
- ALTER DATABASE命令允許針對一個數據庫覆蓋其全局設置。
- ALTER ROLE命令允許用用戶指定的值來覆蓋全局設置和數據庫設置。
隻有當開始一個新的數據庫會話時，用ALTER DATABASE和 ALTER ROLE設置的值才會被應用。它們會覆蓋從配置文件或服務器命令行 獲得的值，並且作為該會話後續的默認值。注意某些設置在服務器啟動後不能被更改，並且因此 不能被這些命令（或者下文列舉的命令）設置。
一旦一個客戶端連接到數據庫，PostgreSQL會提供兩個額外的SQL命令（ 以及等效的函數）用以影響會話本地的配置設置：
- SHOW命令允許察看所有參數的當前值。對應的函數是 current_setting(setting_name text)。
- SET命令允許修改對於一個會話可以本地設置的參數的當前值， 它對其他會話沒有影響。對應的函數是 set_config(setting_name, new_value, is_local)。
此外，係統視圖pg_settings可以被用來查看和改變 會話本地的值：
- 查詢這個視圖與使用SHOW ALL相似，但是可以提供更多細節。它也更加靈活， 因為可以為它指定過濾條件或者把它與其他關係進行連接。
- 在這個視圖上使用UPDATE並且指定更新setting 列，其效果等同於發出SET命令。例如，下麵的命令
SET configuration_parameter TO DEFAULT;
等效於：
UPDATE pg_settings SET setting = reset_val WHERE name = 'configuration_parameter';
除postgresql.conf之外，PostgreSQL 數據目錄還包含一個文件 postgresql.auto.conf，它具有和postgresql.conf相同的格式但是不應該被手工編輯。這個 文件保存了通過ALTER SYSTEM命令提供的設置。每當postgresql.conf被讀 取時這個文件會被自動讀取，並且它的設置會以同樣的方式生效。 postgresql.auto.conf中的設置會覆蓋postgresql.conf 中的設置。
係統視圖pg_file_settings 可以有助於對配置文件中的更改進行提前測試，或者在SIGHUP 信號沒有達到預期效果時用來診斷問題。
1.4. 通過 Shell 影響參數
除了在數據庫或者角色層麵上設置全局默認值或者進行覆蓋，你還可以通過 shell 工具把設置 傳遞給PostgreSQL。服務器和libpq 客戶端庫都能通過 shell 接受參數值。
- 在服務器啟動期間，可以通過-c命令行參數把參數設置傳遞給 postgres命令。例如：
postgres -c log_connections=yes -c log_destination='syslog'
這種方式提供的設置會覆蓋通過postgresql.conf或者 ALTER SYSTEM提供的設置，因此除了重啟服務器之外無法從全局上改變它們。
- 當通過libpq啟動一個客戶端會話時，可以使用PGOPTIONS 環境變量指定參數設置。這種方式建立的設置構成了會話生存期間的默認值，但是不會影響 其他的會話。由於曆史原因，PGOPTIONS的格式和啟動 postgres命令時用到的相似，特別是-c標誌必須被指定。 例如：
env PGOPTIONS="-c geqo=off -c statement_timeout=5min" psql
通過 shell 或者其他方式，其他客戶端和庫可能提供它們自己的機製，以便允許用戶在不直接 使用SQL命令的前提下修改會話設置。
1.5. 管理配置文件內容
PostgreSQL提供了一些特性用於把複雜的 postgresql.conf文件分解成子文件。在管理多個具有相關但不完全相同 配置的服務器時，這些特性特別有用。
除了單個參數設置，postgresql.conf文件可以包含包括指令，它指定要讀入和處理的另一個文件，就好像該文件被插入到配置文件的這個點。這個特性允許一個配置文件被劃分成物理上獨立的部分。包括指令看起來像：
include 'filename'
如果文件名不是一個絕對路徑，它將作為包含引用配置文件的目錄的相對位置。包括可以被嵌套。
也有一個include_if_exists指令，它的作用和include指令一樣，不過當被引用的文件不存在或者無法被讀取時其行為不同。一個通常的include將認為這是一個錯誤情況，而include_if_exists僅僅記錄一個消息並且繼續處理引用配置文件。
postgresql.conf文件也可以包含include_dir指令，它指定要被包含的配置文件的一整個目錄。它的用法類似：
include_dir 'directory'
非絕對目錄名被當做包含引用配置文件的目錄的相對路徑。在該指定目錄中，隻有以後綴名 .conf結尾的非目錄文件才會被包括。以. 字符開頭的文件名也會被忽略，因為在某些平台上它們是隱藏文件。一個包括目錄中的多個文件 被以文件名順序處理（根據 C 區域規則排序，即數字在字母之前並且大寫字母在小寫字母 之前）。
包括文件或目錄可以被用來在邏輯上分隔數據庫配置的各個部分，而不是用一個很大的postgresql.conf文件。考慮一個有兩台數據庫服務器的公司，每一個都有不同的內存量。很可能配置的元素都會被共享，例如用於日誌的參數。但是兩者關於內存的參數將會不同。並且還可能會有服務器相關的自定義。一種管理這類情況的方法是將你的站點的自定義配置修改分成三個文件。你可以把下麵的內容加入到你的postgresql.conf文件末尾來包括它們：
include 'shared.conf'
include 'memory.conf'
include 'server.conf'
所有的係統將會有相同的shared.conf。每個有特定內存量的服務器可以共享相同的memory.conf。你可能對所有 8GB 內存的服務器有一個，而對那些 16GB 內存的服務器有另一個。並且最後server.conf可以裝有真正服務器相關的配置信息。
另一中可能性是創建一個配置文件目錄並把這個信息放到其中的文件裏。例如，一個conf.d目錄可以在postgresql.conf的末尾被引用：
include_dir 'conf.d'
然後你可以這樣命名conf.d目錄中的文件：
00shared.conf
01memory.conf
02server.conf
這種命名習慣建立了這些文件將被載入的清晰順序。這是很重要的，因為在服務器讀取配置 文件時，對於一個特定的參數隻有最後碰到的一個設置才會被使用。在這個例子中， conf.d/02server.conf設置的東西將會覆蓋在 conf.d/01memory.conf中相同參數的值。
你還可以使用這種配置目錄方法，在命名文件時更有描述性：
00shared.conf
01memory-8GB.conf
02server-foo.conf
這種形式的安排為每個配置文件變體給定了一個唯一的名稱。當多個服務器把它們的配置全部存儲在一個位置（例如在一個版本控製倉庫中）時，這可以幫助消除歧義（在版本控製下存儲數據庫配置文件是另一個值得考慮的好方法）。
除了已經提到過的postgresql.conf文件之外，PostgreSQL還使用另外兩個手工編輯的配置文件，它們控製客戶端認證（其使用在Chapter 20中討論）。默認情況下，所有三個配置文件都存放在數據庫集簇的數據目錄中。 本節描述的參數允許配置文件放在別的地方（這麼做可以簡化管理，特別是如果配置文件被獨立放置，可以很容易保證它得到恰當的備份）。
data_directory (string)
指定用於數據存儲的目錄。這個選項隻能在服務器啟動時設置。
config_file (string)
指定主服務器配置文件（通常叫postgresql.conf）。這個參數隻能在postgres命令行上設置。
hba_file (string)
指定基於主機認證配置文件（通常叫pg_hba.conf）。 這個參數隻能在服務器啟動的時候設置。
ident_file (string)
指定用於Section 20.2用戶名稱映射的配置文件（通常叫pg_ident.conf）。這個參數隻能在服務器啟動的時候設置。
external_pid_file (string)
指定可被服務器創建的用於管理程序的額外進程 ID（PID）文件。這個參數隻能在服務器啟動的時候設置。
在默認安裝中不會顯式設置以上參數。相反，命令行參數-D或者環境變量PGDATA指定數據目錄，並且上述配置文件都能在數據目錄中找到。
如果你想把配置文件放在別的地方而不是數據目錄中，那麼postgres -D命令行選項或者環境變量PGDATA必須指向包含配置文件的目錄，並且postgresql.conf中（或者命令行上）的data_directory參數必須顯示數據目錄實際存放的地方。請注意，data_directory將覆蓋-D和PGDATA指定的數據目錄位置，但是不覆蓋配置文件的位置。
如果你願意，可以使用選項config_file、hba_file和/或ident_file單獨指定配置文件名稱和位置。config_file隻能在postgres命令行上指定，但是其他文件可以在主配置文件中設置。如果所有三個參數外加data_directory被顯式地設置，則不必指定-D或PGDATA。
在設置任何這些參數時，相對路徑將被解釋為相對於postgres啟動路徑的路徑。
3.1. 連接設置
listen_addresses (string)
指定服務器在哪些 TCP/IP 地址上監聽客戶端連接。值的形式是一個逗號分隔的主機名和/或數字 IP 地址列表。特殊項*對應所有可用 IP 接口。項0.0.0.0允許監聽所有 IPv4 地址並且::允許監聽所有 IPv6 地址。如果列表為空，服務器將根本不會監聽任何 IP 接口，在這種情況中隻能使用 Unix 域套接字來連接它。默認值是localhost，它隻允許建立本地 TCP/IP "環回"連接。雖然客戶端認證（Chapter 20）允許細粒度地控製誰能訪問服務器，listen_addresses控製哪些接口接受連接嚐試，這能幫助在不安全網絡接口上阻止重複的惡意連接請求。這個參數隻能在服務器啟動時設置。
port (integer)
服務器監聽的 TCP 端口；默認是 5432 。請注意服務器會同一個端口號監聽所有的 IP 地址。這個參數隻能在服務器啟動時設置。
max_connections (integer)
決定數據庫的最大並發連接數。默認值通常是 100 個連接，但是如果內核設置不支持（initdb時決定），可能會比這個 數少。這個參數隻能在服務器啟動時設置。
當運行一個後備服務器時，你必須設置這個參數等於或大於主服務器上的參數。否則，後備服務器上可能無法允許查詢。
superuser_reserved_connections (integer)
決定為PostgreSQL超級用戶連接而保留的連接"槽"數。 同時活躍的並發連接最多max_connections個。任何時候，活躍的並發連接數最多為max_connections減去 superuser_reserved_connections，新連接就隻能由超級用戶發起了，並且不會有新的複製連接被接受。
默認值是 3 。這個值必須小於max_connections的值。 這個參數隻能在服務器啟動時設置。
unix_socket_directories (string)
指定服務器用於監聽來自客戶端應用的連接的 Unix 域套接字目錄。通過列出用逗號分隔的多個目錄可以建立多個套接字。項之間的空白被忽略，如果你需要在名字中包括空白或逗號，在目錄名周圍放上雙引號。一個空值指定在任何 Unix 域套接字上都不監聽，在這種情況中隻能使用 TCP/IP 套接字來連接到服務器。默認值通常是/tmp，但是在編譯時可以被改變。這個參數隻能在服務器啟動時設置。
除了套接字文件本身（名為.s.PGSQL.nnnn，其中nnnn是服務器的端口號），一個名為.s.PGSQL.nnnn.lock的普通文件會在每一個unix_socket_directories目錄中被創建。任何一個都不應該被手工移除。
Windows下沒有 Unix 域套接字，因此這個參數與 Windows 無關。
unix_socket_group (string)
設置 Unix 域套接字的所屬組（套接字的所屬用戶總是啟動服務器的用戶）。可以與選項unix_socket_permissions一起用於對 Unix域連接進行訪問控製。默認是一個空字符串，表示服務器用戶的默認組。這個參數隻能在服務器啟動時設置。
Windows 下沒有 Unix 域套接字，因此這個參數與 Windows 無關。
unix_socket_permissions (integer)
設置 Unix 域套接字的訪問權限。Unix 域套接字使用普通的 Unix 文件係統權限集。這個參數值應該是數字的形式，也就是係統調用chmod和umask接受的 形式（如果使用自定義的八進製格式，數字必須以一個0（零）開頭）。
默認的權限是0777，意思是任何人都可以連接。合理的候選是0770（隻有用戶和同組的人可以訪問， 又見unix_socket_group）和0700（隻有用戶自己可以訪問）（請注意，對於 Unix 域套接字，隻有寫權限有麻煩，因此沒有對讀取和執行權限的設置和收回）。
這個訪問控製機製與Chapter 20中的用戶認證沒有關係。
這個參數隻能在服務器啟動時設置。
這個參數與完全忽略套接字權限的係統無關，尤其是自版本10以上的Solaris。 在那些係統上，可以通過把unix_socket_directories指向一個把搜索權限 限製給指定用戶的目錄來實現相似的效果。 因為 Windows 下沒有 Unix 域套接字，因此這個參數也與 Windows 無關。
bonjour (boolean)
通過Bonjour廣告服務器的存在。默認值是關閉。 這個參數隻能在服務器啟動時設置。
bonjour_name (string)
指定Bonjour服務名稱。空字符串''（默認值）表示使用計算機名。 如果編譯時沒有打開Bonjour支持那麼將忽略這個參數。這個參數隻能在服務器啟動時設置。
tcp_keepalives_idle (integer)
指定不活動多少秒之後通過 TCP 向客戶端發送一個 keepalive 消息。 0 值表示使用默認值。這個參數隻有在支持TCP_KEEPIDLE或TCP_KEEPALIVE符號的係統或 Windows 上才可以使用。在其他係統上，它必須為零。在通過 Unix 域套接字連接的會話中，這個參數被忽略並且總是讀作零。
Note:
在 Windows 上，值若為 0，係統會將該參數設置為 2 小時，因為 Windows 不支持讀取係統默認值。
tcp_keepalives_interval (integer)
指定在多少秒之後重發一個還沒有被客戶端告知已收到的 TCP keepalive 消息。0 值表示使用係統默認值。這個參數隻有在支持TCP_KEEPINTVL符號的係統或 Windows 上才可以使用。在其他係統上，必須為零。在通過 Unix域套接字連接的會話中，這個參數被忽略並總被讀作零。
Note: 在 Windows 上，值若為 0，係統會將該參數設置為 1 秒，因為 Windows 不支持讀取係統默認值。
tcp_keepalives_count (integer)
指定與客戶端的服務器連接被認為死掉之前允許丟失的 TCP keepalive 數量。0 值表示使用係統默認值。這個參數隻有在支持TCP_KEEPCNT符號的係統上才可以使用。在其他係統上，必須為零。在通過 Unix 域套接字連接的會話中，這個參數被忽略並總被讀作零。
Note:
Windows 不支持該參數，且必須為零。
3.2. 安全和認證
authentication_timeout (integer)
完成客戶端認證的最長時間，以秒計。如果一個客戶端沒有在這段時間裏完成 認證協議，服務器將關閉連接。這樣就避免了出問題的客戶端無限製地占有一個連接。默認值是 1分鍾（1m）。這個參數隻能在服務器命令行上或者在postgresql.conf文件中設置。
ssl (boolean)
啟用SSL連接。請在使用這個參數之前閱讀Section 18.9。默認是off。 這個選項隻能在服務器啟動時設置。SSL通信隻能和 TCP/IP 連接一起使用。
ssl_ca_file (string)
指定包含 SSL 服務器證書頒發機構（CA）的文件名。默認值為空，表示不載入 CA 文件，並且不執行客戶端證書驗證（在之前的 PostgreSQL 發布中，這個文件的名字被硬編碼成root.crt）。相對路徑是相對於數據目錄。這個參數隻能在服務器啟動時設置。
ssl_cert_file (string)
指定包含 SSL 服務器證書的文件名。默認值是server.crt。相對路徑是相對於數據目錄的。這個參數隻能在服務器啟動時設置。
ssl_crl_file (string)
指定包含 SSL 服務器證書撤銷列表（CRL）的文件名。默認值為空，意味著不載入 CRL 文件（在之前的 PostgreSQL 發布中，這個文件的名稱被硬編碼為root.crl）。相對路徑是相對於數據目錄。這個參數隻能在服務器啟動時設置。
ssl_key_file (string)
指定包含 SSL 服務器私鑰的文件名。默認值為server.key。 相對路徑是相對於數據目錄。這個參數隻能在服務器啟動時設置。
ssl_ciphers (string)
指定一個SSL密碼列表，用於安全連接。這個設置的語法和所支持的值列表可以 參見OpenSSL包中的 ciphers手冊頁。默認值是 HIGH:MEDIUM:+3DES:!aNULL。它通常是合理的，除非你有特別的安全性需求。
默認值的解釋：
HIGH
使用來自HIGH組的密碼的密碼組（例如 AES, Camellia, 3DES）
MEDIUM
使用來自MEDIUM組的密碼的密碼組（例如 RC4, SEED）
+3DES
OpenSSL 對HIGH的默認排序是有問題的，因為它認為 3DES 比 AES128 更高。這是錯誤的，因為 3DES 提供的安全性比 AES128 低，並且它也更加慢。 +3DES把它重新排序在所有其他HIGH和 MEDIUM密碼之後。
!aNULL
禁用不做認證的匿名密碼組。這類密碼組容易收到中間人攻擊，因此不應被使用。
可用的密碼組細節可能會隨著 OpenSSL 版本變化。可使用命令 openssl ciphers -v 'HIGH:MEDIUM:+3DES:!aNULL'來查看 當前安裝的OpenSSL版本的實際細節。注意這個列表是根據服務器密鑰類型 在運行時過濾過的。
ssl_prefer_server_ciphers (bool)
指定是否使用服務器的 SSL 密碼首選項，而不是用客戶端的。默認為真。
老的PostgreSQL版本沒有這個設置並且總是使用客戶端的首選項。這個設置主要用於與那些版本 的向後兼容性。使用服務器的首選項通常會更好，因為服務器更可能會被合適地配置。
ssl_ecdh_curve (string)
指定用在ECDH密鑰交換中的曲線名稱。它需要被所有連接的客戶端支持。 它不需要與服務器橢圓曲線密鑰使用的曲線相同。默認值是prime256v1。
OpenSSL 命名了最常見的曲線： prime256v1 (NIST P-256)、 secp384r1 (NIST P-384)、 secp521r1 (NIST P-521)。
openssl ecparam -list_curves命令可以顯示可用曲線的完 整列表。不過並不是所有的都在TLS中可用。
password_encryption (boolean)
當在CREATE USER或ALTER ROLE中指定了一個密碼，而沒有寫ENCRYPTED或UNENCRYPTED時，這個參數決定是否密碼會被加密。默認值是on（加密密碼）。
krb_server_keyfile (string)
設置 Kerberos 服務器密鑰文件的位置。詳見Section 20.3.3。這個參數隻能在 postgresql.conf文件中或服務器命令行上進行設置。
krb_caseins_users (boolean)
設置 Kerberos 和 GSSAPI 用戶名是否應區分大小寫。默認是off（區分大小寫）。這個參數隻能在 postgresql.conf文件中或服務器命令行上進行設置。
db_user_namespace (boolean)
允許針對每個數據庫的用戶名。默認是關閉的。這個參數隻能在 postgresql.conf文件中或服務器命令行上進行設置。
如果打開這個參數，你應該以username@dbname的方式創建用戶。 當一個username被連接著的客戶端傳遞時，@和數據庫名被增加到用戶名中並且那個數據庫相關的用戶名會被服務器查找。注意，當你在 SQL 環境裏創建包含@的用戶名時， 你需要用引號包圍用戶名。
打開這個參數之後，你還是能夠創建普通的全局用戶。隻要在客戶端指定用戶名時附加一個@，例如joe@。 在服務器查找這個用戶名之前，這個@會被剝除。
db_user_namespace導致客戶端和服務器的用戶名表示變得不同。 認證檢查總是使用服務器用戶名來完成，因此認證方法必須為服務器的用戶名配置，而不是客戶端的用戶名。因為在客戶端和服務器上md5都使用用戶名作為鹽粒，md5不能和db_user_namespace一起使用。
Note:
這個特性隻是一種臨時方法，直到找到一個完全的解決方案。那個時候， 這個選項將被刪除。
4.1. 內存
shared_buffers (integer)
設置數據庫服務器將使用的共享內存緩衝區量。默認通常是 128 兆字節（128MB），但是如果你的內核設置不支持（在initdb時決定），那麼可以會更少。這個設置必須至少為 128 千字節（BLCKSZ的非默認值將改變最小值）。不過為了更好的性能，通常會使用明顯高於最小值的設置。
如果有一個專用的 1GB 或更多內存的數據庫服務器，一個合理的shared_buffers開始值是係統內存的 25%。即使很大的shared_buffers有效，也會造成一些工作負載， 但因為PostgreSQL同樣依賴操作係統的高速緩衝區，將shared_buffers設置為超過 40% 的RAM不太可能比一個小點值工作得更好。為了能把對寫大量新的或改變的數據的處理分布在一個較長的時間段內，shared_buffers更大的設置通常要求對max_wal_size也做相應增加。
如果係統內存小於 1GB，一個較小的 RAM 百分數是合適的，這樣可以為操作係統留下足夠的空間。 同時，在 Windows 上，shared_buffers設置得較大也不一定有效。你會發現保持相對低的設置並且更多使用操作係統高速緩存會得到更好的結果。Windows 上可用的shared_buffers值通常是從 64MB 到 512 MB。
huge_pages (enum)
啟用/禁用巨型內存頁麵的使用。可用的值是 try（默認）、on、 和off。
當前，隻有 Linux 上支持這個特性。在其他係統上這個參數被設置為 try時，它會被忽略。
巨型頁麵的使用會導致更小的頁麵表以及花費在內存管理上的 CPU 時間更少，從而提高性能。
當huge_pages被設置為try時，服務器將 嚐試使用巨型頁麵，如果失敗則會轉回去使用正常的分配。如果設置為 on，使用巨型頁麵失敗會阻止服務器啟動。如果設置為 off，則不會使用巨型頁麵。
temp_buffers (integer)
設置每個數據庫會話使用的臨時緩衝區的最大數目。這些都是會話的本地緩衝區，隻用於訪問臨時表。默認是 8 兆字節（8MB）。這個設置可以在獨立的會話內部被改變，但是隻有在會話第一次使用臨時表之前才能改變； 在會話中隨後企圖改變該值是無效的。
一個會話將按照temp_buffers給出的限製根據需要分配臨時緩衝區。如果在一個並不需要大量臨時緩衝區的會話裏設置一個大的數值， 其開銷隻是一個緩衝區描述符，或者說temp_buffers每增加一則增加大概 64 字節。不過，如果一個緩衝區被實際使用，那麼它就會額外消耗 8192 字節（或者BLCKSZ字節）。
max_prepared_transactions (integer)
設置可以同時處於"prepared"狀態的事務的最大數目（見PREPARE TRANSACTION）。把這個參數設置 為零（這是默認設置）將禁用預備事務特性。這個參數隻能在服務器啟動時設置。
如果你不打算使用預備事務，可以把這個參數設置為零來防止意外創建預備事務。如果你正在使用預備事務，你將希望把max_prepared_transactions至少設置為max_connections一樣大，因此每一個會話可以有一個預備事務待處理。
當運行一個後備服務器時，這個參數必須至少與主服務器上的一樣大。否則，後備服務器上將不會執行查詢。
work_mem (integer)
指定在寫到臨時磁盤文件之前被內部排序操作和哈希表使用的內存量。該值默認為四兆字節（4MB）。注意對於一個複雜查詢， 可能會並行運行好幾個排序或者哈希操作；每個操作都會被允許使用這個參數指定的內存量，然後才會開始寫數據到臨時文件。同樣，幾個正在運行的會話可能並發進行這樣的操作。因此被使用的總內存可能是work_mem值的好幾倍，在選擇這個值時一定要記住這一點。ORDER BY、DISTINCT和歸並連接都要用到排序操作。哈希連接、基於哈希的聚集以及基於哈希的IN子查詢處理中都要用到哈希表。
maintenance_work_mem (integer)
指定在維護性操作（例如VACUUM、CREATE INDEX和ALTER TABLE ADD FOREIGN KEY）中使用的 最大的內存量。其默認值是 64 兆字節（64MB）。因為在一個數據庫會話中，一個時刻隻有一個這樣的操作可以被執行，並且一個數據庫安裝通常不會有太多這樣的操作並發執行， 把這個數值設置得比work_mem大很多是安全的。 更大的設置可以改進清理和恢複數據庫轉儲的性能。
注意當自動清理運行時，可能會分配這個內存的autovacuum_max_workers倍，因此要小心不要把該默認值設置得太高。
注意當自動清理運行時，可能會分配最多達這個內存的autovacuum_max_workers倍，因此要小心不要把該默認值設置得太高。 通過獨立地設置autovacuum_work_mem可能會對控製這種情況 有所幫助。
replacement_sort_tuples (integer)
當要被排序的元組數比這個數字小時，排序將會使用替換選擇而不是快速排序來產生其第一個輸出。在內存受限的環境中這可能會有用，這種環境中被輸入到大型排序操作中的元組具有很強的物理邏輯關聯。注意，這不包括具有逆相關的輸入元組。替換選擇算法可能會產生一次不需要合並的長時間運行，其中使用默認策略會導致很多次運行並且必須被合並來產生最終的有序輸出。這可以允許排序操作更快完成。
默認是 150,000 個元組。注意，更高的值通常不會更有效，並且可能產生反效果，因為優先隊列對於可用的 CPU 高速緩存的尺寸很敏感，然而默認策略會使用一種高速緩存透明算法運行。這種性質允許默認的排序策略自動且透明地利用可用的 CPU 高速緩存。
Setting 把maintenance_work_mem設置為其默認值通常會阻止工具命令外部排序（例如CREATE INDEX用來構建 B-樹索引的排序）使用替換選擇排序，除非外部元組非常寬。
autovacuum_work_mem (integer)
指定每個自動清理工作者進程能使用的最大內存量。其默認值為 -1，表示轉而使用 maintenance_work_mem的值。當運行在其他上下文環境中時， 這個設置對VACUUM的行為沒有影響。
max_stack_depth (integer)
指定服務器的執行堆棧的最大安全深度。這個參數的理想設置是由內核強製的實際棧尺寸限製（ulimit -s所設置的或者本地等價物），減去大約一兆字節的安全邊緣。需要這個安全邊緣是因為在服務器中並非所有例程都檢查棧深度，隻是在關鍵的可能遞規的例程（例如表達式計算）中才進行檢查。默認設置是兩兆字節（2MB），這個值相對比較小並且不可能導致崩潰。但是，這個值可能太小了，以至於無法執行複雜的函數。隻有超級用戶可以修改這個設置。
把max_stack_depth參數設置得高於實際的內核限製將意味著一個失控的遞歸函數可能會導致一個獨立的後端進程崩潰。 在PostgreSQL能夠檢測內核限製的平台上， 服務器將不允許把這個參數設置為一個不安全的值。不過，並非所有平台都能提供該信息，所以我們還是建議你在選擇值時要小心。
dynamic_shared_memory_type (enum)
指定服務器應該使用的動態共享內存實現。可能的值是posix（用於使用 shm_open分配的 POSIX 共享內存）、sysv （用於通過shmget分配的 System V 共享內存）、 windows（用於 Windows 共享內存）、mmap （使用存儲在數據目錄中的內存映射文件模擬共享內存）以及none（禁用 這個特性）。並非所有平台上都支持所有值，平台上第一個支持的選項就是其默認值。 在任何平台上mmap選項都不是默認值，通常不鼓勵使用它，因為操作係統會 反複地把修改過的頁麵寫回到磁盤上，從而增加了係統的I/O負載。不過當 pg_dynshmem目錄被存儲在一個 RAM 盤時或者沒有其他共享內存功能可用時， 它還是有用的。
4.2. 磁盤
temp_file_limit (integer)
指定一個進程能用於臨時文件（如排序和哈希臨時文件，或者用於保持遊標的存儲文件）的最大磁盤空間量。一個試圖超過這個限製的事務將被取消。這個值以千字節計，並且-1（默認值）意味著沒有限製。隻有超級用戶能夠修改這個設置。
這個設置約束著一個給定PostgreSQL進程在任何瞬間所使用的所有臨時文件的總空間。應該注意的是，與在查詢執行中在幕後使用的臨時文件相反，顯式臨時表所用的磁盤空間不被這個設置所限製。
4.3. 內核資源使用
max_files_per_process (integer)
設置每個服務器子進程允許同時打開的最大文件數目。默認是 1000 個文件。如果內核強製一個安全的針對每個進程的限製，那麼你不用操心這個設置。但是在 一些平台上（特別是大多數 BSD 係統），如果很多進程都嚐試打開很多文件，內核將允許獨立進程打開比個係統真正可以支持的數目大得多得文件數。如果你發現自己看到了"Too many open files"這樣的失敗，可嚐試減小這個設置。這個參數隻能在服務器啟動時設置。
4.4. 基於代價的清理延遲
在VACUUM和ANALYZE命令的執行過程中，係統維持著一個內部計數器來跟蹤各種被執行的I/O操作的估算開銷。當累計的代價達到一個限製（由vacuum_cost_limit指定），執行這些操作的進程將按照vacuum_cost_delay所指定的休眠一小段時間。然後它將重置計數器並繼續執行。
這個特性的出發點是允許管理員降低這些命令對並發的數據庫活動產生的I/O影響。在很多情況下，VACUUM和ANALYZE等維護命令能否快速完成並不重要，而非常重要的是這些命令不會對係統執行其他數據庫操作的能力產生顯著的影響。基於代價的清理延遲提供了一種方式讓管理員能夠保證這一點。
對於手動發出的VACUUM命令，該特性默認被禁用。要啟用它，隻要把vacuum_cost_delay變量設為一個非零值。
vacuum_cost_delay (integer)
進程超過代價限製後將休眠的時間長度，以毫秒計。其默認值為0，這將禁用基於代價的清理延遲特性。正值將啟用基於代價的清理。注意在很多係統上，實際的休眠延遲單位是10毫秒，將vacuum_cost_delay設置成不為10的倍數的值和將它設置為比該值大的10的倍數的效果相同。
在使用基於代價的清理時，vacuum_cost_delay的合適值通常很小，也許是10或20毫秒。調整清理時資源消耗最好的方法是調整其他清理代價參數。
vacuum_cost_page_hit (integer)
清理一個在共享緩存中找到的緩衝區的估計代價。它表示鎖住緩衝池、查找共享哈希表和掃描頁內容的代價。默認值為1。
vacuum_cost_page_miss (integer)
清理一個必須從磁盤上讀取的緩衝區的代價。它表示鎖住緩衝池、查找共享哈希表、從磁盤讀取需要的塊以及掃描其內容的代價。默認值為10。
vacuum_cost_page_dirty (integer)
當清理修改一個之前幹淨的塊時需要花費的估計代價。它表示再次把髒塊刷出到磁盤所需要的額外I/O。默認值為20。
vacuum_cost_limit (integer)
將導致清理進程休眠的累計代價。默認值為200。
Note:
有些操作會保持關鍵性的鎖，這樣可以盡快完成。基於代價的清理延遲在這類操作期間不會發生。因此有可能代價會累計至大大超過指定的限製。為了防止在這種情況下的無意義的長時間延遲，實際延遲的計算方式是vacuum_cost_delay * accumulated_balance / vacuum_cost_limit，且最大值是vacuum_cost_delay * 4。
4.5. 後台寫入器
有一個獨立的服務器進程，叫做後台寫入器，它的功能就是發出寫"髒"（新的或修改過的）共享緩衝區的命令。它寫出共享緩衝區，這樣讓處理用戶查詢的服務器進程很少或者永不等待寫動作的發生。不過，後台寫入器確實會增加 I/O 的總負荷，因為雖然在每個檢查點間隔中一個重複弄髒的頁麵可能隻會寫出一次，但在同一個間隔中後台寫入器可能會把它寫出好幾次。在這一小節討論的參數可以被用於調節本地需求的行為。
bgwriter_delay (integer)
指定後台寫入器活動輪次之間的延遲。在每個輪次中，寫入器都會為一定數量的髒緩衝區發出寫操作（可以用下麵的參數控製）。然後它就休眠 bgwriter_delay毫秒， 然後重複動作。默認值是 200 毫秒（200ms）。注意在許多係統上，休眠延遲的有效解析度是 10 毫秒；因此，為bgwriter_delay設置一個 不是 10 的倍數的值與把它設置為下一個更高的 10 的倍數是一樣的效果。這個選項隻能在服務器命令行上或者在postgresql.conf文件中設置。
bgwriter_lru_maxpages (integer)
在每個輪次中，不超過這麼多個緩衝區將被後台寫入器寫出。把這個參數設置為零可禁用後台寫出（注意被一個獨立、專用輔助進程管理的檢查點不受影響）。默認值是 100 個緩衝區。這個參數隻能在postgresql.conf文件中或在服務器命令行上設置。
bgwriter_lru_multiplier (floating point)
每一輪次要寫的髒緩衝區的數目基於最近幾個輪次中服務器進程需要的新緩衝區的數目。 最近所需的平均值乘以bgwriter_lru_multiplier可以估算下一輪次中將會需要的緩衝區數目。髒緩衝區將被寫出直到有很多幹淨可重用的緩衝區（然而，每一輪次中寫出的緩衝區數不超過bgwriter_lru_maxpages）。 因此，設置為 1.0 表示一種"剛剛好的"策略，這種策略會寫出正好符合預測值的數目的緩衝區。 更大大的值可以為需求高峰提供某種緩衝，而更小的值則需要服務進程來處理一些寫出操作。默認值是 2.0。這個參數隻能在postgresql.conf文件中或在服務器命令行上設置。
bgwriter_flush_after (integer)
不管何時 bgwriter 寫入了超過bgwriter_flush_after字節，嚐試強製 OS 把這些寫發送到底層存儲上。這樣做將限製內核頁緩存中髒數據的量，降低了在檢查點末尾發出一個 fsync 時或者 OS 在後台大批量寫回數據時卡住的可能性。那常常會導致大幅度壓縮的事務延遲，但是也有一些情況（特別是負載超過shared_buffers但小於 OS 頁麵高速緩存）的性能會降低。這種設置可能會在某些平台上沒有效果。合法的範圍在0（禁用受控寫回）和2MB之間。Linux 上的默認值是512kB，其他平台上是0（非默認的BLCKSZ值會改變默認值和最大值）。這個參數隻能在postgresql.conf文件中或者服務器命令行上設置。
較小的bgwriter_lru_maxpages和bgwriter_lru_multiplier可以降低由後台寫入器造成的額外 I/O 開銷。但更可能的是，服務器進程將必須自己發出寫入操作，這會延遲交互式查詢。
4.6. 異步行為
effective_io_concurrency (integer)
設置PostgreSQL可以同時被執行的並發磁盤 I/O 操作的數量。調高這個值，可以增加任何單個PostgreSQL會話試圖並行發起的 I/O 操作的數目。 允許的範圍是 1 到 1000，或 0 表示禁用異步 I/O 請求。當前這個設置僅影響位圖堆掃描。
對於磁盤驅動器，這個設置的一個很好的出發點是組成一個被用於該數據庫的 RAID 0 條帶或 RAID 1 鏡像的獨立驅動器數量（對 RAID 5 而言，校驗驅動器不計入）。但是， 如果數據庫經常忙於在並發會話中發出的多個查詢，較低的值可能足以使磁盤陣列繁忙。比保持磁盤繁忙所需的值更高的值隻會造成額外的 CPU 開銷。SSD 以及其他基於內存的存儲常常能處理很多並發請求，因此它們的最佳值可能是數百。
異步 I/O 依賴於一個有效的posix_fadvise函數（一些操作係統可能沒有）。 如果不存在這個函數，將這個參數設置為除 0 之外的任何東西將導致錯誤。在一些操作係統上（如Solaris）雖然提供了這個函數，但它不會做任何事情。
在支持的係統上默認值為 1，否則為 0。對於一個特定表空間中的表，可以通過設定該表空間的同名參數（見ALTER TABLESPACE）可以覆蓋這個值。
max_worker_processes (integer)
設置係統能夠支持的後台進程的最大數量。這個參數隻能在服務器啟動時設置。默認值為 8。
在運行一個後備服務器時，你必須把這個參數設置為等於或者高於主控服務器上的值。否則， 後備服務器上可能不會允許查詢。
max_parallel_workers_per_gather (integer)
設置單個Gather節點能夠開始的工作者的最大數量。並行工作者會從max_worker_processes建立的進程池中取得。注意所要求的工作者數量在運行時可能實際無法被滿足。如果這種事情發生，該計劃將會以比預期更少的工作者運行，這可能會不太高效。把這個值設置為 0（默認值）將會禁用並行查詢執行。
注意並行查詢可能消耗比非並行查詢更多的資源，因為每一個工作者進程時一個完全獨立的進程，它對係統產生的影響大致和一個額外的用戶會話相同。在為這個設置選擇值時，以及配置其他控製資源利用的設置（例如work_mem）時，應該把這個因素考慮在內。work_mem之類的資源限製會被獨立地應用於每一個工作者，這意味著所有進程的總資源利用可能會比單個進程時高得多。例如，一個使用 4 個工作者的並行查詢使用的 CPU 時間、內存、I/O 帶寬可能是不使用工作者時的 5 倍之多。
backend_flush_after (integer)
隻要一個後端寫入了超過backend_flush_after字節，就會嚐試強製 OS 把這些寫發送到底層存儲。這樣做將會限製內核頁高速緩存中的髒數據數量，降低在檢查點末尾發出 fsync 時或者 OS 在後台大批寫回數據時卡住的可能性。這常常會導致極大降低的事務延遲，但是也有一些情況中（特別是負載超過shared_buffers但低於 OS 的頁麵高速緩存時），性能可能會下降。這個設置可能在某些平台上沒有效果。合法的範圍位於0（禁用受控寫回）和2MB之間。默認是0（即沒有刷寫控製）。（BLCKSZ的非默認值會更改最大值）。
old_snapshot_threshold (integer)
設置在使用快照時，一個快照可以被使用而沒有發生snapshot too old錯誤風險的最小時間。這個參數隻能在服務器啟動時設置。
如果超過該閾值，舊數據將被清理掉。這可以有助於阻止長時間使用的快照造成的快照膨脹。為了阻止由於本來對該快照可見的數據被清理導致的不正確結果，當快照比這個閾值更舊並且該快照被用來讀取一個該快照建立以來被修改過的頁麵時，將會產生一個錯誤。
值為-1會禁用這個特性，並且這個值是默認值。對於生產工作有用的值可能從幾個小時到幾天。該設置將被轉換成分鍾粒度，並且小數字（例如0或者1min）被允許隻是因為它們有時對於測試有用。雖然允許高達60d的設置，但是請注意很多負載情況下，很短的時間幀裏就可能發生極大的膨脹或者事務 ID 回卷。
當這個特性被啟用時，關係末尾的被清出的空間不能被釋放給操作係統，因為那可能會移除用於檢測snapshot too old情況所需的信息。所有分配給關係的空間還將與該關係關聯在一起便於重用，除非它們被顯式地釋放（例如，用VACUUM FULL）。
這個設置不會嚐試保證在任何特殊情況下都會生成錯誤。事實上，如果（例如）可以從一個已經物化了一個結果集的遊標中生成正確的結果，即便被引用表中的底層行已經被清理掉也不會生成錯誤。某些表不能被過早地安全清除，並且因此將不受這個設置的影響。例子包括係統目錄以及任何具有哈希索引的表。對於這些表，這個設置將不能降低膨脹，也不能降低在掃描時產生snapshot too old錯誤的可能性。
5.1. 設置
wal_level (enum)
wal_level決定多少信息寫入到 WAL 中。默認值是minimal， 隻寫入從崩潰或立即關機恢複所需要的信息。replica添加 WAL 歸檔所需要的日誌以及在一個後備服務器上運行隻讀查詢所需的信息。最後，logical會增加支持邏輯解碼所需的信息。每個層次包括所有更低層次記錄的信息。這個參數隻能在服務器啟動時設置。
在minimal級別中，某些批量操作的 WAL 日誌可以被安全地跳過，這可以使那些操作更快。這種優化可以應用的操作包括：
CREATE TABLE AS
CREATE INDEX
CLUSTER
COPY到在同一個事務中被創建或截斷的表中
但最少的 WAL 不會包括足夠的信息來從基礎備份和 WAL 日誌中重建數據，因此，要啟用 WAL 歸檔（archive_mode）和流複製，必須使用replica或更高級別。
在logical層，與replica相同的信息會被記錄，外加上 允許從 WAL 抽取邏輯修改集所需的信息。使用級別 logical將增加 WAL 容量，特別是如果為了REPLICA IDENTITY FULL配置了很多表並且執行了很多UPDATE和DELETE 語句時。
在 9.6 之前的版本中，這個參數也允許值archive和hot_standby。現在仍然接受這些值，但是它們會被映射到replica。
fsync (boolean)
如果打開這個參數，PostgreSQL服務器將嚐試確保更新被物理地寫入到磁盤，做法是發出fsync()係統調用或者使用多種等價的方法（見wal_sync_method）。這保證了數據庫集簇在一次操作係統或者硬件崩潰後能恢複到一個一致的狀態。
雖然關閉fsync常常可以得到性能上的收益，但當發生斷電或係統崩潰時可能造成不可恢複的數據損壞。因此，隻有在能很容易地從外部數據中重建整個數據庫時才建議關閉fsync。
能安全關閉fsync的環境的例子包括從一個備份文件中初始加載一個新數據庫集簇、使用一個數據庫集簇來在數據庫被刪掉並重建之後處理一批數據，或者一個被經常重建並卻不用於失效備援的隻讀數據庫克隆。單獨的高質量硬件不足以成為關閉fsync的理由。
當把fsync從關閉改成打開時，為了可靠的恢複，需要強製在內核中的所有被修改的緩衝區進入持久化存儲。這可以在多個時機來完成：在集簇被關閉時或在 fsync 因為運行initdb --sync-only而打開時、運行sync時、卸載文件係統時或者重啟服務器時。
在很多情況下，為不重要的事務關閉synchronous_commit可以提供很多關閉fsync的潛在性能收益，並不會有的同時， 關閉fsync可以提供很多潛在的性能優勢，而不會有伴隨著的數據損壞風險。
fsync隻能在postgresql.conf文件中或在服務器命令行上設置。如果你關閉這個參數，請也考慮關閉full_page_writes。
synchronous_commit (enum)
指定在命令返回"success"指示給客戶端之前，一個事務是否需要等待 WAL 記錄被寫入磁盤。合法的值是on、remote_apply、remote_write、local和off。默認的並且安全的設置是on。當設置為off時，在向客戶端報告成功和真正保證事務不會被服務器崩潰威脅之間會有延遲（最大的延遲是wal_writer_delay的三倍）。不同於fsync，將這個參數設置為off不會產生數據庫不一致性的風險：一個操作係統或數據庫崩潰可能會造成一些最近據說已提交的事務丟失，但數據庫狀態是一致的，就像這些事務已經被幹淨地中止。因此，當性能比完全確保事務的持久性更重要時，關閉synchronous_commit可以作為一個有效的代替手段。更多討論見Section 30.3。
如果synchronous_standby_names為非空，這個參數也控製事務提交是否將等待它們的 WAL 記錄被複製到後備服務器上。當這個參數被設置為on時，直到來自於當前同步的後備服務器的回複指示它們已經收到了事務的提交記錄並將其刷入了磁盤，主服務器上的事務才會提交。這保證事務將不會被丟失，除非主服務器和所有同步後備都遭受到了數據庫存儲損壞的問題。當被設置為remote_apply時，提交將會等待，直到來自當前的同步後備的回複指示它們已經收到了該事務的提交記錄並且已經應用了該事務，這樣該事務才變得對後備上的查詢可見。當這個參數被設置為remote_write時，提交將等待，直到來自當前的同步後備的回複指示它們已經收到了該事務的提交記錄並且已經把該記錄寫出到它們的操作係統，這種設置足以保證數據在後備服務器的PostgreSQL實例崩潰時得以保存，但是不能保證後備服務器遭受操作係統級別崩潰時數據能被保持，因為數據不一定必須要在後備機上達到穩定存儲。最後，設置local會導致提交等待本地刷寫到磁盤而不是複製完成。在使用同步複製時這通常不是我們想要的效果，但是為了完整性，還是提供了這樣一個選項。
如果synchronous_standby_names為空，設置on、remote_apply、remote_write和local都提供了同樣的同步級別：事務提交隻等待本地刷寫磁盤。
這個參數可以隨時被修改；任何一個事務的行為由其提交時生效的設置決定。因此，可以同步提交一些事務，同時異步提交其他事務。例如，當默認是相反時，實現一個單一多語句事務的異步提交，在事務中發出SET LOCAL synchronous_commit TO OFF。
wal_sync_method (enum)
用來向強製 WAL 更新到磁盤的方法。如果fsync是關閉的，那麼這個設置就不相關，因為 WAL 文件更新將根本不會被強製。可能的值是：
- open_datasync（用open()選項O_DSYNC寫 WAL 文件）
- fdatasync（在每次提交時調用fdatasync()）
- fsync（在每次提交時調用fsync()）
- fsync_writethrough（在每次提交時調用fsync()，強製任何磁盤寫高速緩存的直通寫）
- open_sync（用open()選項O_SYNC寫 WAL 文件）
open_* 選項也可以使用O_DIRECT（如果可用）。不是在所有平台上都能使用所有這些選擇。默認值是列表中第一個被平台支持的那個， 不過fdatasync是 Linux 中的默認值。默認值不一定是最理想的；有可能需要修改這個設置或係統配置的其他方麵來創建一個崩潰-安全的配置，或達到最佳性能。這些方麵在Section 30.1中討論。這個參數隻能在postgresql.conf文件中或在服務器命令行上設置。
full_page_writes (boolean)
當這個參數為打開時，PostgreSQL服務器在一個檢查點之後的頁麵的第一次修改期間將每個頁麵的全部內容寫到 WAL 中。這麼做是因為在操作係統崩潰期間正在處理的一次頁寫入可能隻有部分完成，從而導致在一個磁盤頁麵中混合有新舊數據。在崩潰後的恢複期間，通常存儲在 WAL 中的行級改變數據不足以完全恢複這樣一個頁麵。存儲完整的頁麵映像可以保證頁麵被正確存儲，但代價是增加了必須被寫入 WAL 的數據量（因為 WAL 重放總是從一個檢查點開始，所以在檢查點後每個頁麵的第一次改變時這樣做就夠了。因此，一種減小全頁麵寫開銷的方法是增加檢查點間隔參數值）。
把這個參數關閉會加快正常操作，但是在係統失敗後可能導致不可恢複的數據損壞，或者靜默的數據損壞。其風險類似於關閉fsync， 但是風險較小。並且隻有在可關閉fsync的情況下才應該關閉它。
關閉這個選項並不影響用於時間點恢複（PITR）的 WAL 歸檔使用（見Section 25.3）。
這個參數隻能在postgresql.conf文件中或在服務器命令行上設置。默認值是on。
wal_log_hints (boolean)
當這個參數為on時，PostgreSQL服務器一個檢查點之後頁麵被第一次修改期間把該磁盤頁麵的整個內容都寫入 WAL，即使對所謂的提示位做非關鍵修改也會這樣做。
如果啟用了數據校驗和，提示位更新總是會被 WAL 記錄並且這個設置會被忽略。你可以使用這個 設置測試如果你的數據庫啟用了數據校驗和，會有多少額外的 WAL 記錄發生。
這個參數隻能在服務器啟動時設置。默認值是off。
wal_compression (boolean)
當這個參數為on時，如果full_page_writes 為打開或者處於基礎備份期間，PostgreSQL服務器 會壓縮寫入到 WAL 中的完整頁麵鏡像。壓縮頁麵鏡像將在 WAL 重放時 被解壓。默認值為off。隻有超級用戶可以更改這個設置。
打開這個參數可以減小 WAL 所占的空間且無需承受不可恢複的數據損壞風險， 但是代價是需要額外的 CPU 開銷以便在 WAL 記錄期間進行壓縮以及在 WAL 重放時解壓。
wal_buffers (integer)
用於還未寫入磁盤的 WAL 數據的共享內存量。默認值 -1 選擇等於shared_buffers的 1/32 的尺寸（大約3%），但是不小於64kB也不大於 WAL 段的尺寸（通常為）。如果自動的選擇太大或太小可以手工設置該值，但是任何小於32kB的正值都將被當作32kB。這個參數隻能在服務器啟動時設置。
在每次事務提交時，WAL 緩衝區的內容被寫出到磁盤，因此極大的值不可能提供顯著的收益。不過，把這個值設置為幾個兆字節可以在一個繁忙的服務器（其中很多客戶端會在同一時間提交）上提高寫性能。由默認設置 -1 選擇的自動調節將在大部分情況下得到合理的結果。
wal_writer_delay (integer)
指定 WAL 寫入器刷寫 WAL 的頻繁程度。在刷寫 WAL 之後它會睡眠wal_writer_delay毫秒，除非被一個異步提交事務喚醒。假如上一次刷寫發生在少於wal_writer_delay毫秒以前並且從上一次刷寫發生以來產生了少於wal_writer_flush_after字節的 WAL，WAL 將隻被寫入到 OS 而不是被刷到磁盤。默認值是 200 毫秒（200ms）。注意在很多係統上，有效的睡眠延遲粒度是 10 毫秒，把wal_writer_delay設置為一個不是 10 的倍數的值，其效果和把它設置為大於該值的下一個 10 的倍數產生的效果相同。這個參數隻能在postgresql.conf文件中或者服務器命令行上設置。
wal_writer_flush_after (integer)
指定 WAL 寫入器刷寫 WAL 的頻繁程度。在刷寫 WAL 之後它會睡眠wal_writer_delay毫秒，除非被一個異步提交事務喚醒。假如上一次刷寫發生在少於wal_writer_delay毫秒以前並且從上一次刷寫發生以來產生了少於wal_writer_flush_after字節的 WAL，WAL 將隻被寫入到 OS 而不是被刷到磁盤。如果wal_writer_flush_after被設置為0，則每次 WAL 寫入器寫完 WAL 之後 WAL 就會被刷寫。默認是1MB。這個參數隻能在postgresql.conf文件中或者服務器命令行上設置。
commit_delay (integer)
在一次 WAL 刷寫被發起之前，commit_delay增加一個時間延遲，以微妙計。如果係統負載足夠高，使得在一個給定間隔內有額外的事務準備好提交，那麼通過允許更多事務通過一個單次 WAL 刷寫來提交能夠提高組提交的吞吐量。但是，它也把每次 WAL 刷寫的潛伏期增加到了最多commit_delay微秒。因為如果沒有其他事務準備好提交，就會浪費一次延遲，隻有在當一次刷寫將要被發起時有至少commit_siblings個其他活動事務時，才會執行一次延遲。另外，如果fsync被禁用，則將不會執行任何延遲。默認的commit_delay是零（無延遲）。隻有超級用戶才能修改這個設置。
在PostgreSQL的 9.3 發布之前，commit_delay的行為不同並且效果更差：它隻影響提交，而不是所有 WAL 刷寫，並且即使在 WAL 刷寫馬上就要完成時也會等待一整個配置的延遲。從PostgreSQL 9.3 中開始，第一個準備好刷寫的進程會等待配置的間隔，而後續的進程隻等到領先者完成刷寫操作。
commit_siblings (integer)
在執行commit_delay延遲時，要求的並發活動事務的最小數目。大一些的值會導致在延遲間隔期間更可能有至少另外一個事務準備好提交。默認值是五個事務。
5.2. 檢查點
checkpoint_timeout (integer)
自動 WAL 檢查點之間的最長時間，以秒計。合理的範圍在 30 秒到 1 天之間。默認是 5 分鍾（5min）。增加這個參數的值會增加崩潰恢複所需的時間。這個參數隻能在postgresql.conf文件中或在服務器命令行上設置。
checkpoint_completion_target (floating point)
指定檢查點完成的目標，作為檢查點之間總時間的一部分。默認是 0.5。 這個參數隻能在postgresql.conf文件中或在服務器命令行上設置。
checkpoint_flush_after (integer)
在執行檢查點時，隻要有checkpoint_flush_after字節被寫入，就嚐試強製 OS 把這些寫發送到底層存儲。這樣做將會限製內核頁麵高速緩存中的髒數據數量，降低在檢查點末尾發出 fsync 或者 OS 在後台大批量寫回數據時被卡住的可能性。那常常會導致大幅度壓縮的事務延遲，但是也有一些情況（特別是負載超過shared_buffers但小於 OS 頁麵高速緩存）的性能會降低。這種設置可能會在某些平台上沒有效果。合法的範圍在0（禁用受控寫回）和2MB之間。Linux 上的默認值是256kB，其他平台上是0（非默認的BLCKSZ值會改變默認值和最大值）。這個參數隻能在postgresql.conf文件中或者服務器命令行上設置。
checkpoint_warning (integer)
如果由於填充檢查點段文件導致的檢查點之間的間隔低於這個參數表示的秒數，那麼就向服務器日誌寫一個消息（它建議增加max_wal_size的值）。默認值是 30 秒（30s）。零則關閉警告。如果checkpoint_timeout低於checkpoint_warning，則不會有警告產生。這個參數隻能在postgresql.conf文件中或在服務器命令行上設置。
max_wal_size (integer)
在自動 WAL 檢查點之間允許 WAL 增長到的最大尺寸。這是一個軟限製， 在特殊的情況下 WAL 尺寸可能會超過max_wal_size， 例如在重度負荷下、archive_command失敗或者高的 wal_keep_segments設置。默認為 1 GB。增加這個參數 可能導致崩潰恢複所需的時間。這個參數隻能在postgresql.conf 或者服務器命令行中設置。
min_wal_size (integer)
隻要 WAL 磁盤用量保持在這個設置之下，在檢查點時舊的 WAL 文件總是 被回收以便未來使用，而不是直接被刪除。這可以被用來確保有足夠的 WAL 空間被保留來應付 WAL 使用的高峰，例如運行大型的批處理任務。 默認是 80 MB。這個參數隻能在postgresql.conf 或者服務器命令行中設置。
5.3. 歸檔
archive_mode (enum)
當啟用archive_mode時，可以通過設置 archive_command命令將完成的 WAL 段發送到 歸檔存儲。除用於禁用的off之外，還有兩種模式： on和always。在普通操作期間，這兩種模式之間 沒有區別，但是當設置為always時，WAL 歸檔器在歸檔恢複 或者後備模式下也會被啟用。在always模式下，所有從歸檔恢複 的或者用流複製傳來的文件將被（再次）歸檔。
archive_mode和archive_command是獨立的變量，這樣可以在不影響歸檔模式的前提下修改archive_command。這個參數隻能在服務器啟動時設置。當wal_level被設置為minimal時，archive_mode不能被啟用。
archive_command (string)
本地 shell 命令被執行來歸檔一個完成的 WAL 文件段。字符串中的任何%p被替換成要被歸檔的文件的路徑名， 而%f隻被文件名替換（路徑名是相對於服務器的工作目錄， 即集簇的數據目錄）。如果要在命令裏嵌入一個真正的%字符，可以使用%%。有一點很重要，該命令隻在成功時返回一個零作為退出狀態。
這個參數隻能在postgresql.conf文件中或在服務器命令行上設置。除非服務器啟動時啟用了archive_mode，否則它會被忽略。如果archive_mode被啟用時，archive_command是一個空字符串（默認），WAL 歸檔會被臨時禁用，但服務器仍會繼續
最後更新：2017-08-21 17:32:36