關於調整這些設定的更多資訊，請參閱第 28.5 節。
wal_level (enum) #wal_level 決定有多少資訊會寫入 WAL。預設值為 replica，它會寫入足夠的資料來支援 WAL 歸檔和複製，包括在待命伺服器上執行唯讀查詢。minimal 會移除除了從崩潰或立即關機中復原所需資訊之外的所有日誌記錄。最後，logical 會新增支援邏輯解碼所需的資訊。每個層級都包含在所有較低層級記錄的資訊。此參數只能在伺服器啟動時設定。
minimal 層級產生的 WAL 體積最小。它不會記錄建立或重寫它們的交易中永久關係的任何列資訊。這可以使操作快得多（請參閱第 14.4.7 節）。啟動此最佳化的操作包括
ALTER ... SET TABLESPACE |
CLUSTER |
CREATE TABLE |
REFRESH MATERIALIZED VIEW（沒有 CONCURRENTLY） |
REINDEX |
TRUNCATE |
但是，最小 WAL 不包含用於時間點復原的足夠資訊，因此必須使用 replica 或更高的層級才能啟用連續歸檔（archive_mode）和串流二進位制複製。實際上，如果 max_wal_senders 非零，伺服器甚至不會在此模式下啟動。請注意，將 wal_level 變更為 minimal 會使先前的基礎備份無法用於時間點復原和待命伺服器。
在 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 只能在 postgresql.conf 檔案或伺服器命令列中設定。如果您關閉此參數，也請考慮關閉 full_page_writes。
synchronous_commit (enum) #指定在資料庫伺服器將 「成功」指示回傳給用戶端之前，必須完成多少 WAL 處理。有效值為 remote_apply、on (預設值)、remote_write、local 和 off。
如果 synchronous_standby_names 為空，則唯一有意義的設定是 on 和 off； remote_apply、remote_write 和 local 都提供與 on 相同的本地同步層級。 所有非 off 模式的本地行為都是等待 WAL 本地刷新到磁碟。 在 off 模式下，沒有等待，因此在將成功報告給用戶端的時間，與稍後保證交易可免於伺服器崩潰的時間之間，可能會存在延遲。（最大延遲是 wal_writer_delay 的三倍。） 與 fsync 不同，將此參數設定為 off 不會產生任何資料庫不一致的風險：作業系統或資料庫崩潰可能會導致遺失一些最近宣稱已提交的交易，但資料庫狀態將與這些交易被乾淨中止時的狀態相同。 因此，當效能比交易耐用性的確切確定性更重要時，關閉 synchronous_commit 可能是一個有用的替代方案。 有關更多討論，請參閱 第 28.4 節。
如果 synchronous_standby_names 為非空，則 synchronous_commit 也會控制交易提交是否會等待其 WAL 紀錄在備用伺服器上處理。
當設定為 remote_apply 時，提交將等待來自當前同步備用伺服器的回覆，指示它們已收到交易的提交紀錄並已套用，因此它已對備用伺服器上的查詢可見，並且也已寫入備用伺服器上的持久儲存裝置。 這將導致比先前的設定更大的提交延遲，因為它會等待 WAL 重播。 當設定為 on 時，提交將等待來自當前同步備用伺服器的回覆，指示它們已收到交易的提交紀錄並將其刷新到持久儲存裝置。 這可確保交易不會遺失，除非主伺服器和所有同步備用伺服器都遭受其資料庫儲存裝置的損壞。 當設定為 remote_write 時，提交將等待來自當前同步備用伺服器的回覆，指示它們已收到交易的提交紀錄並將其寫入其檔案系統。 如果 PostgreSQL 的備用實例崩潰，此設定可確保資料保存，但如果備用伺服器遭受作業系統層級的崩潰，則無法確保資料保存，因為資料不一定已到達備用伺服器上的持久儲存裝置。 設定 local 會導致提交等待本地刷新到磁碟，但不等待複寫。 這通常在使用同步複寫時不希望發生，但為了完整性而提供。
此參數可以隨時更改；任何一個交易的行為由提交時生效的設定決定。因此，有可能且有用的是，讓某些交易同步提交，而另一些交易非同步提交。例如，要使單個多語句交易在預設為相反時非同步提交，請在交易中發出 SET LOCAL synchronous_commit TO OFF。
表 19.1 總結了 synchronous_commit 設定的功能。
表 19.1. synchronous_commit 模式
| synchronous_commit 設定 | 本地持久提交 | PG 崩潰後的備用持久提交 | 作業系統崩潰後的備用持久提交 | 備用查詢一致性 |
|---|---|---|---|---|
| remote_apply | • | • | • | • |
| on | • | • | • | |
| remote_write | • | • | ||
| local | • | |||
| 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 檔案)
並非所有平台上都提供所有這些選項。預設值是平台支援的上述列表中第一個方法，除了 Linux 和 FreeBSD 上的預設值為 fdatasync。預設值不一定是理想的；可能需要更改此設定或系統組態的其他方面，才能建立崩潰安全的組態或實現最佳效能。這些方面在 第 28.1 節 中討論。此參數只能在 postgresql.conf 檔案或伺服器命令列中設定。
full_page_writes (boolean) #當啟用此參數時，PostgreSQL 伺服器會在檢查點之後第一次修改磁碟頁面時，將整個磁碟頁面的內容寫入 WAL。這是必要的，因為在作業系統崩潰期間正在進行的頁面寫入可能只會部分完成，導致磁碟上的頁面包含新舊資料的混合。通常儲存在 WAL 中的列級變更資料將不足以在崩潰後的復原期間完全恢復此類頁面。儲存完整的頁面映像可確保頁面能夠正確恢復，但代價是必須寫入 WAL 的資料量會增加。（因為 WAL 重播始終從檢查點開始，因此在檢查點之後的每個頁面的第一次變更時執行此操作就足夠了。因此，減少完整頁面寫入成本的一種方法是增加檢查點間隔參數。）
關閉此參數會加快正常操作，但可能會導致系統故障後出現無法復原的資料損毀，或靜默的資料損毀。風險與關閉 fsync 類似，但較小，只有在建議該參數的相同情況下才應將其關閉。
關閉此參數不會影響使用 WAL 歸檔進行時間點復原 (PITR)（請參閱第 25.3 節）。
此參數只能在 postgresql.conf 檔案中或伺服器命令列上設定。預設值為 on。
wal_log_hints (boolean) #當此參數為 on 時，PostgreSQL 伺服器會在檢查點之後第一次修改磁碟頁面時，將整個磁碟頁面的內容寫入 WAL，即使是對所謂的提示位元 (hint bits) 進行非關鍵修改也是如此。
如果啟用了資料校驗和，則始終會將提示位元更新記錄到 WAL 中，並且會忽略此設定。您可以使用此設定來測試，如果您的資料庫啟用了資料校驗和，則會發生多少額外的 WAL 記錄。
此參數只能在伺服器啟動時設定。預設值為 off。
wal_compression (enum) #此參數使用指定的壓縮方法啟用 WAL 壓縮。啟用後，當 full_page_writes 為 on 時或在基本備份期間，PostgreSQL 伺服器會壓縮寫入 WAL 的完整頁面映像。壓縮的頁面映像將在 WAL 重播期間解壓縮。支援的方法為 pglz、lz4（如果 PostgreSQL 是使用 --with-lz4 編譯的）和 zstd（如果 PostgreSQL 是使用 --with-zstd 編譯的）。預設值為 off。只有超級使用者和具有適當 SET 權限的使用者才能變更此設定。
啟用壓縮可以減少 WAL 體積，而不會增加無法復原的資料損毀的風險，但代價是在 WAL 記錄期間花費一些額外的 CPU 進行壓縮，並在 WAL 重播期間花費一些額外的 CPU 進行解壓縮。
wal_init_zero (boolean) #如果設定為 on（預設值），此選項會導致新的 WAL 檔案以零填充。在某些檔案系統上，這可確保在我們需要寫入 WAL 記錄之前已分配空間。但是，Copy-On-Write (COW) 檔案系統可能無法從此技術中受益，因此提供了跳過不必要工作的選項。如果設定為 off，則僅在建立檔案時寫入最後一個位元組，以便它具有預期的容量。
wal_recycle (boolean) #如果設定為 on（預設值），此選項會導致透過重新命名來回收 WAL 檔案，避免建立新檔案的需要。在 COW 檔案系統上，建立新檔案可能會更快，因此提供了禁用此行為的選項。
wal_buffers (integer) #用於尚未寫入磁碟的 WAL 資料的共用記憶體量。預設設定 -1 選擇的容量等於 shared_buffers 的 1/32（約 3%），但不小於 64kB 也不大於一個 WAL 區段的大小，通常為 16MB。如果自動選擇太大或太小，則可以手動設定此值，但任何小於 32kB 的正值都將被視為 32kB。如果未指定單位，則此值採用 WAL 區塊，即 XLOG_BLCKSZ 個位元組，通常為 8kB。此參數只能在伺服器啟動時設定。
WAL 緩衝區的內容會在每次交易提交時寫出到磁碟，因此極大的值不太可能提供顯著的益處。但是，將此值設定為至少幾 MB 可以改善繁忙伺服器上的寫入效能，其中許多用戶端同時提交。預設設定 -1 選擇的自動調整應該在大多數情況下提供合理的結果。
wal_writer_delay (integer) #指定 WAL 寫入器刷新 WAL 的頻率，以時間計算。刷新 WAL 後，寫入器會休眠 wal_writer_delay 指定的時間長度，除非被非同步提交的交易提前喚醒。如果上次刷新發生在小於 wal_writer_delay 之前，並且自那之後產生的 WAL 小於 wal_writer_flush_after 的值，則 WAL 僅寫入到作業系統，而不刷新到磁碟。如果未指定單位，則此值採用毫秒為單位。預設值為 200 毫秒 (200ms)。請注意，在某些系統上，睡眠延遲的有效解析度為 10 毫秒；將 wal_writer_delay 設定為非 10 的倍數的值可能與將其設定為下一個較高的 10 的倍數的值具有相同的結果。此參數只能在 postgresql.conf 檔案中或伺服器命令列上設定。
wal_writer_flush_after (integer) #指定 WAL 寫入器刷新 WAL 的頻率，以資料量計算。如果上次刷新發生在小於 wal_writer_delay 之前，且自那之後產生的 WAL 資料量小於 wal_writer_flush_after，則 WAL 僅寫入作業系統，而不刷新到磁碟。如果 wal_writer_flush_after 設定為 0，則 WAL 資料始終立即刷新。如果未指定單位，則此值被視為 WAL 區塊，即 XLOG_BLCKSZ 位元組，通常為 8kB。預設值為 1MB。此參數只能在 postgresql.conf 檔案或伺服器命令列中設定。
wal_skip_threshold (integer) #當 wal_level 為 minimal 且交易在建立或重寫永久關聯後提交時，此設定決定如何持久儲存新資料。如果資料小於此設定值，則將其寫入 WAL 日誌；否則，對受影響的檔案使用 fsync。根據儲存的特性，提高或降低此值可能會有幫助，如果此類提交減慢了並行交易。如果未指定單位，則此值被視為 KB。預設值為兩 MB (2MB)。
commit_delay (integer) #設定 commit_delay 會在啟動 WAL 刷新之前增加一個時間延遲。如果系統負載足夠高，以至於在給定時間間隔內有更多交易準備好提交，這可以通過允許更多數量的交易通過單個 WAL 刷新來提交，從而提高群組提交吞吐量。但是，它也將每次 WAL 刷新的延遲增加到最多 commit_delay。因為如果沒有其他交易準備好提交，則延遲只是浪費，所以只有當至少有 commit_siblings 個其他交易在啟動刷新時處於活動狀態時，才會執行延遲。此外，如果禁用 fsync，則不執行延遲。如果未指定單位，則此值被視為微秒。預設的 commit_delay 為零 (無延遲)。只有超級使用者和具有適當 SET 權限的使用者才能變更此設定。
在 9.3 之前的 PostgreSQL 版本中，commit_delay 的行為不同，效果也差得多：它僅影響提交，而不影響所有 WAL 刷新，並且即使 WAL 刷新更快完成，也會等待整個配置的延遲。從 PostgreSQL 9.3 開始，第一個準備好刷新的程序會等待配置的時間間隔，而後續程序僅等待領導者完成刷新操作。
commit_siblings (integer) #執行 commit_delay 延遲之前所需的最小並行開啟交易數。較大的值使得在延遲間隔期間至少另一個交易將準備好提交的可能性更大。預設值為五個交易。
checkpoint_timeout (integer) #自動 WAL 檢查點之間的最大時間。如果未指定單位，則此值被視為秒。有效範圍介於 30 秒到一天之間。預設值為五分鐘 (5min)。增加此參數可能會增加崩潰恢復所需的時間。此參數只能在 postgresql.conf 檔案或伺服器命令列中設定。
checkpoint_completion_target (floating point) #指定檢查點完成的目標，作為檢查點之間總時間的一部分。預設值為 0.9，這將檢查點分散到幾乎所有可用間隔，在提供相當一致的 I/O 負載的同時，也為檢查點完成開銷留下一些時間。不建議降低此參數，因為它會導致檢查點更快完成。這會導致在檢查點期間有更高的 I/O 速率，然後在檢查點完成和下一個排定的檢查點之間有一段較少的 I/O 時間。此參數只能在 postgresql.conf 檔案或伺服器命令列中設定。
checkpoint_flush_after (integer) #每當在執行檢查點時寫入的資料量超過此量時，嘗試強制作業系統將這些寫入發送到基礎儲存裝置。這樣做將限制核心頁面快取中的髒資料量，從而減少在檢查點結束時發出 fsync 時或作業系統在背景中以較大批次寫回資料時發生停頓的可能性。通常，這將導致大大降低的交易延遲，但也存在一些情況，尤其是在工作負載大於 shared_buffers 但小於作業系統的頁面快取時，效能可能會降低。此設定在某些平台上可能沒有效果。如果未指定單位，則此值被視為區塊，即 BLCKSZ 位元組，通常為 8kB。有效範圍介於 0（禁用強制寫回）和 2MB 之間。預設值在 Linux 上為 256kB，在其他地方為 0。(如果 BLCKSZ 不是 8kB，則預設值和最大值會與之成比例縮放。) 此參數只能在 postgresql.conf 檔案或伺服器命令列中設定。
checkpoint_warning (integer) #如果由 WAL 區段檔案填滿引起的檢查點發生時間間隔小於此值（這表示應該提高 max_wal_size），則將訊息寫入伺服器日誌。如果未指定單位，則此值被視為秒。預設值為 30 秒 (30s)。零會停用警告。如果 checkpoint_timeout 小於 checkpoint_warning，則不會產生警告。此參數只能在 postgresql.conf 檔案或伺服器命令列中設定。
max_wal_size (integer) #自動檢查點期間允許 WAL 增長的最大大小。這是一個軟性限制；在特殊情況下，例如負載過重、archive_command 或 archive_library 失敗或 wal_keep_size 設定較高時，WAL 大小可能會超過 max_wal_size。如果此值在指定時沒有單位，則預設為 MB。預設值為 1 GB。增加此參數可能會增加崩潰恢復所需的時間。此參數只能在 postgresql.conf 檔案中或在伺服器命令列上設定。
min_wal_size (integer) #只要 WAL 磁碟使用量低於此設定，舊的 WAL 檔案始終會在檢查點被回收以供將來使用，而不是被移除。這可用於確保有足夠的 WAL 空間被保留，以應對 WAL 使用量的峰值，例如在執行大型批次作業時。如果此值在指定時沒有單位，則預設為 MB。預設值為 80 MB。此參數只能在 postgresql.conf 檔案中或在伺服器命令列上設定。
archive_mode (enum) #當啟用 archive_mode 時，已完成的 WAL 片段會透過設定 archive_command 或 archive_library 來傳送到封存儲存。除了 off (用於停用) 之外，還有兩種模式：on 和 always。在正常運作期間，這兩種模式沒有區別，但設定為 always 時，WAL 封存器也會在封存恢復或待機模式期間啟用。在 always 模式下，從封存還原或透過串流複製串流的所有檔案都會（再次）被封存。有關詳細資訊，請參閱第 26.2.9 節。
archive_mode 是與 archive_command 和 archive_library 分開的設定，因此可以在不離開封存模式的情況下更改 archive_command 和 archive_library。此參數只能在伺服器啟動時設定。當 wal_level 設定為 minimal 時，無法啟用 archive_mode。
archive_command (string) #用於執行以封存已完成 WAL 檔案片段的本機 shell 命令。字串中的任何 %p 都會被要封存的檔案的路徑名稱取代，而任何 %f 都只會被檔案名稱取代。（路徑名稱相對於伺服器的工作目錄，即叢集的資料目錄。）使用 %% 在命令中嵌入實際的 % 字元。重要的是，該命令只有在成功時才返回零退出狀態。有關更多資訊，請參閱第 25.3.1 節。
此參數只能在 postgresql.conf 檔案中或在伺服器命令列上設定。它僅在伺服器啟動時啟用了 archive_mode 且 archive_library 設定為空字串時使用。如果同時設定了 archive_command 和 archive_library，則會引發錯誤。如果 archive_command 是一個空字串（預設值），而 archive_mode 已啟用（且 archive_library 設定為空字串），則 WAL 封存會暫時停用，但伺服器會繼續累積 WAL 片段檔案，期望很快會提供一個命令。將 archive_command 設定為一個除了返回 true 之外什麼也不做的命令，例如 /bin/true（Windows 上為 REM），實際上會停用封存，但也會破壞封存恢復所需的 WAL 檔案鏈，因此僅應在特殊情況下使用。
archive_library (string) #用於封存已完成 WAL 檔案片段的函式庫。如果設定為空字串（預設值），則啟用透過 shell 進行封存，並且使用 archive_command。如果同時設定了 archive_command 和 archive_library，則會引發錯誤。否則，指定的共享函式庫將用於封存。當此參數變更時，postmaster 會重新啟動 WAL 封存器進程。有關更多資訊，請參閱第 25.3.1 節和第 49 章。
此參數只能在 postgresql.conf 檔案中或在伺服器命令列上設定。
archive_timeout (integer) #只有針對已完成的 WAL 片段才會呼叫 archive_command 或 archive_library。因此，如果您的伺服器產生的 WAL 流量很少（或有產生 WAL 流量的寬鬆時段），則事務完成與將其安全地記錄在封存儲存體中之間可能會存在很長的延遲。為了限制未封存資料的舊程度，您可以設定 archive_timeout 以強制伺服器定期切換到新的 WAL 片段檔案。當此參數大於零時，自上次片段檔案切換以來經過的時間超過此設定值，並且有任何資料庫活動（包括單個檢查點）時，伺服器將會切換到新的片段檔案（如果沒有資料庫活動，則跳過檢查點）。請注意，由於強制切換而提前關閉的封存檔案的長度仍然與完全完整的檔案相同。因此，使用非常短的 archive_timeout 是不明智的 - 它會膨脹您的封存儲存體。一分鐘左右的 archive_timeout 設定通常是合理的。如果您希望資料比封存更快地從主伺服器複製出去，則應考慮使用串流複製，而不是封存。如果此值在指定時沒有單位，則預設為秒。此參數只能在 postgresql.conf 檔案中或在伺服器命令列上設定。
本節描述了通常適用於恢復的設定，影響崩潰恢復、串流複製和基於封存的複製。
recovery_prefetch (enum) #在恢復期間，是否嘗試預先提取 WAL 中引用但尚未在緩衝池中的區塊。有效值為 off、on 和 try（預設值）。設定 try 僅在作業系統提供 posix_fadvise 函數時啟用預先提取，目前使用該函數來實現預先提取。請注意，某些作業系統提供了該函數，但它什麼也不做。
預先提取 (Prefetching) 很快就會需要的區塊，可以減少某些工作負載在恢復期間的 I/O 等待時間。另請參閱 wal_decode_buffer_size 和 maintenance_io_concurrency 設定，它們限制了預先提取的活動。
wal_decode_buffer_size (integer) #限制伺服器可以在 WAL 中預先查看多遠，以尋找要預先提取的區塊。如果指定此值時沒有單位，則將其視為位元組。預設值為 512kB。
本節描述僅在恢復期間適用的設定。對於您希望執行的任何後續恢復，必須重置這些設定。
“恢復 (Recovery)”涵蓋將伺服器用作備用伺服器或執行目標恢復。通常，備用模式用於提供高可用性和/或讀取擴展性，而目標恢復則用於從資料遺失中恢復。
若要在備用模式下啟動伺服器，請在資料目錄中建立一個名為 standby.signal 的檔案。伺服器將進入恢復狀態，並且在到達封存檔 WAL 的末尾時不會停止恢復，而是會依照 primary_conninfo 設定所指定的，透過連接到傳送伺服器和/或使用 restore_command 提取新的 WAL 片段，來持續嘗試恢復。對於此模式，本節和第 19.6.3 節中的參數是有用的。來自第 19.5.6 節的參數也將被套用，但在這種模式下通常沒有用處。
若要在目標恢復模式下啟動伺服器，請在資料目錄中建立一個名為 recovery.signal 的檔案。如果同時建立 standby.signal 和 recovery.signal 檔案，則備用模式優先。當封存檔 WAL 完全重播，或達到 recovery_target 時，目標恢復模式結束。在此模式下，將使用本節和第 19.5.6 節中的參數。
restore_command (string) #要執行的本機 Shell 命令，用於檢索 WAL 檔案系列的封存片段。此參數是封存檔恢復所必需的，但對於串流複製是可選的。字串中的任何 %f 都會被要從封存檔檢索的檔案名稱取代，任何 %p 都會被伺服器上的複製目標路徑名稱取代。（路徑名稱相對於目前的工作目錄，即叢集的資料目錄。） 任何 %r 都會被包含最後一個有效重新啟動點的檔案名稱取代。那是必須保留的最早檔案，以便允許可重新啟動的還原，因此此資訊可用於將封存檔截斷為僅支援從目前還原重新啟動所需的最小值。%r 通常僅由暖備用配置使用（請參閱第 26.2 節）。撰寫 %% 以嵌入實際的 % 字元。
重要的是，該命令僅在其成功時才返回零的結束狀態。該命令 將 被要求提供封存檔中不存在的檔案名稱；當被要求時，它必須返回非零值。範例
restore_command = 'cp /mnt/server/archivedir/%f "%p"' restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
一個例外是，如果該命令因訊號（不是用作資料庫伺服器關機一部分的 SIGTERM）或 Shell 的錯誤（例如找不到命令）而終止，則恢復將中止，並且伺服器將不會啟動。
此參數只能在 postgresql.conf 檔案中或在伺服器命令列上設定。
archive_cleanup_command (string) #此可選參數指定在每個重新啟動點將執行的 Shell 命令。archive_cleanup_command 的目的是提供一種機制來清理備用伺服器不再需要的舊封存 WAL 檔案。任何 %r 都會被包含最後一個有效重新啟動點的檔案名稱取代。那是必須保留的最早檔案，以便允許可重新啟動的還原，因此可以安全地移除早於 %r 的所有檔案。此資訊可用於將封存檔截斷為僅支援從目前還原重新啟動所需的最小值。pg_archivecleanup 模組通常在單一備用配置的 archive_cleanup_command 中使用，例如
archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'
但是請注意，如果多個備用伺服器正在從同一個封存檔目錄還原，則您需要確保在任何伺服器不再需要 WAL 檔案之前不要刪除它們。archive_cleanup_command 通常會在暖備用配置中使用（請參閱第 26.2 節）。撰寫 %% 以在命令中嵌入實際的 % 字元。
如果該命令返回非零結束狀態，則會寫入警告日誌訊息。一個例外是，如果該命令因訊號或 Shell 的錯誤（例如找不到命令）而終止，則會引發嚴重錯誤。
此參數只能在 postgresql.conf 檔案中或在伺服器命令列上設定。
recovery_end_command (string) #此參數指定在恢復結束時只執行一次的 Shell 命令。此參數是可選的。recovery_end_command 的目的是提供一種在複製或恢復後進行清理的機制。任何 %r 都會被包含最後一個有效重新啟動點的檔案名稱取代，如archive_cleanup_command 中所示。
如果該命令返回非零結束狀態，則會寫入警告日誌訊息，並且資料庫將繼續啟動。一個例外是，如果該命令因訊號或 Shell 的錯誤（例如找不到命令）而終止，則資料庫將不會繼續啟動。
此參數只能在 postgresql.conf 檔案中或在伺服器命令列上設定。
預設情況下，恢復將恢復到 WAL 日誌的末尾。以下參數可用於指定較早的停止點。最多可以使用 recovery_target、recovery_target_lsn、recovery_target_name、recovery_target_time 或 recovery_target_xid 中的一個；如果在設定檔中指定了多個，則會引發錯誤。這些參數只能在伺服器啟動時設定。
recovery_target = 'immediate' #此參數指定恢復應在達到一致狀態時立即結束，即盡可能早地結束。從線上備份還原時，這表示進行備份結束的點。
從技術上講，這是一個字串參數，但 'immediate' 目前是唯一允許的值。
recovery_target_name (string) #這個參數指定具名的還原點（使用 pg_create_restore_point() 建立），恢復程序將進行到該還原點。
recovery_target_time (timestamp) #這個參數指定恢復程序將進行到的時間戳記。確切的停止點也受到 recovery_target_inclusive 的影響。
此參數的值是時間戳記，格式與 timestamp with time zone 資料類型接受的格式相同，但您不能使用時區縮寫（除非 timezone_abbreviations 變數已在設定檔中較早設定）。首選樣式是使用與 UTC 的數字偏移量，或者您可以寫入完整的時區名稱，例如，Europe/Helsinki 而不是 EEST。
recovery_target_xid (string) #這個參數指定恢復程序將進行到的交易 ID。請記住，雖然交易 ID 在交易開始時依序分配，但交易可以用不同的數字順序完成。將被恢復的交易是在指定的交易之前（且選擇性地包含該交易）提交的交易。確切的停止點也受到 recovery_target_inclusive 的影響。
recovery_target_lsn (pg_lsn) #這個參數指定預寫日誌位置的 LSN，恢復程序將進行到該位置。確切的停止點也受到 recovery_target_inclusive 的影響。此參數使用系統資料類型 pg_lsn 進行剖析。
以下選項進一步指定恢復目標，並影響達到目標時會發生的情況
recovery_target_inclusive (boolean) #指定是在指定的恢復目標之後停止 (on)，還是在恢復目標之前停止 (off)。當指定 recovery_target_lsn、recovery_target_time 或 recovery_target_xid 時適用。此設定控制是否將具有完全目標 WAL 位置 (LSN)、提交時間或交易 ID 的交易包含在恢復中。預設值為 on。
recovery_target_timeline (string) #指定恢復到特定的時間軸。該值可以是數字時間軸 ID 或特殊值。值 current 沿著與建立基礎備份時相同時間軸恢復。值 latest 恢復到封存中找到的最新時間軸，這在待機伺服器中很有用。latest 是預設值。
若要以十六進位指定時間軸 ID（例如，如果從 WAL 檔名或歷史記錄檔中擷取），請在前面加上 0x。例如，如果 WAL 檔名是 00000011000000A10000004F，則時間軸 ID 為 0x11（或十進位 17）。
通常只有在複雜的重新恢復情況下才需要設定此參數，在這些情況下，您需要返回到在時間點恢復之後達到的狀態。 有關討論，請參閱 Section 25.3.6。
recovery_target_action (enum) #指定伺服器在達到恢復目標後應採取的動作。預設值為 pause，表示恢復將暫停。promote 表示恢復過程將完成，並且伺服器將開始接受連線。最後，shutdown 將在達到恢復目標後停止伺服器。
pause 設定的目的是允許對資料庫執行查詢，以檢查此恢復目標是否為恢復最理想的點。可以使用 pg_wal_replay_resume() 恢復暫停狀態（請參閱 Table 9.97），這將導致恢復結束。如果此恢復目標不是所需的停止點，則關閉伺服器，將恢復目標設定變更為較晚的目標，然後重新啟動以繼續恢復。
shutdown 設定有助於使執行個體在所需的確切重播點準備就緒。該執行個體仍然可以重播更多 WAL 記錄（實際上，下次啟動時將必須重播自上次檢查點以來的 WAL 記錄）。
請注意，由於當 recovery_target_action 設定為 shutdown 時，recovery.signal 不會被移除，因此除非變更組態或手動移除 recovery.signal 檔案，否則任何後續啟動都將以立即關閉結束。
如果未設定任何恢復目標，則此設定無效。如果未啟用 hot_standby，則 pause 設定的作用與 shutdown 相同。如果在升級正在進行時達到恢復目標，則 pause 設定的作用與 promote 相同。
在任何情況下，如果已配置恢復目標，但在達到目標之前封存恢復結束，則伺服器將關閉並出現嚴重錯誤。
這些設定控制 WAL 摘要，這項功能必須啟用才能執行增量備份。
summarize_wal (boolean) #啟用 WAL 摘要程序。請注意，WAL 摘要可以在主要節點或備用節點上啟用。此參數只能在 postgresql.conf 檔案中或在伺服器命令行上設定。預設值為 off（關閉）。
如果 wal_level 設定為 minimal，則伺服器無法以 summarize_wal=on 啟動。如果在伺服器啟動後配置 summarize_wal=on，而 wal_level=minimal，則摘要程序將運行，但拒絕為任何以 wal_level=minimal 產生的 WAL 產生摘要檔案。
wal_summary_keep_time (integer) #設定 WAL 摘要程序自動移除舊 WAL 摘要的時間長度。檔案時間戳記用於判斷哪些檔案已過期到足以移除。通常，您應將此值設定為遠大於備份與之後依賴它的增量備份之間可能經過的時間。WAL 摘要必須可用於前一個備份和正在進行的新備份之間的整個 WAL 記錄範圍；如果沒有，增量備份將會失敗。如果此參數設定為零，WAL 摘要將不會自動刪除，但您可以安全地手動移除您知道未來增量備份不需要的檔案。此參數只能在 postgresql.conf 檔案中或在伺服器命令行上設定。如果此值未指定單位，則以分鐘為單位。預設值為 10 天。如果 summarize_wal = off，則無論此參數的值為何，現有的 WAL 摘要都不會被移除，因為 WAL 摘要程序不會運行。
如果您在文件中發現任何不正確、與您對特定功能的體驗不符或需要進一步澄清的地方，請使用此表單回報文件問題。