有關調整這些設定的更多資訊，請參閱第 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 崩潰後備用持久提交 | OS 崩潰後備用持久提交 | 備用查詢一致性 |
|---|---|---|---|---|
| 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 檔案）
並非所有這些選擇在所有平臺上都可用。預設值是列表中第一個平臺支援的方法，但 fdatasync 是 Linux 和 FreeBSD 上的預設值。預設值不一定是最優的；可能需要更改此設定或系統配置的其他方面才能建立崩潰安全配置或實現最佳效能。這些方面在第 28.1 節中進行了討論。此引數只能在 postgresql.conf 檔案或伺服器命令列中設定。
full_page_writes (boolean) #當此引數開啟時，PostgreSQL 伺服器在檢查點後首次修改頁面時，會將每個磁碟頁面的全部內容寫入 WAL。這是必需的，因為在作業系統崩潰期間正在進行的頁面寫入可能只部分完成，導致磁碟上的頁面包含新舊資料混合。通常儲存在 WAL 中的行級更改資料不足以在崩潰後恢復中完全恢復 such a page。儲存完整的頁面映像可以保證頁面可以被正確恢復，但代價是增加了必須寫入 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 壓縮。啟用後，PostgreSQL 伺服器會壓縮寫入 WAL 的全頁映像（例如，當 full_page_writes 開啟時、在基準備份期間等）。壓縮後的頁面映像將在 WAL 重放期間解壓縮。支援的方法包括 pglz、lz4（如果 PostgreSQL 是使用 --with-lz4 編譯的）和 zstd（如果 PostgreSQL 是使用 --with-zstd 編譯的）。預設值為 off。只有超級使用者和具有適當 SET 許可權的使用者才能更改此設定。
啟用壓縮可以減少 WAL 的卷，而不會增加無法恢復的資料損壞的風險，但代價是 WAL 日誌記錄期間的壓縮和 WAL 重放期間的解壓縮會消耗一些額外的 CPU。
wal_init_zero (boolean) #如果設定為 on（預設），此選項會導致新 WAL 檔案被填零。在某些檔案系統上，這可以確保在需要寫入 WAL 記錄之前分配空間。但是，寫時複製（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 緩衝區的內容將在每次事務提交時寫入磁碟，因此非常大的值不太可能提供顯著的好處。但是，將此值設定為至少幾兆位元組可以提高繁忙伺服器上多個客戶端同時提交時的寫入效能。預設設定 -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。根據您的儲存屬性，提高或降低此值可能會在提交減慢併發事務時有所幫助。如果指定此值時不帶單位，則將其視為千位元組。預設值為兩兆位元組（2MB）。
commit_delay (integer) #設定 commit_delay 會在啟動 WAL 重新整理之前增加一個時間延遲。這可以透過允許更多事務透過單個 WAL 重新整理提交來提高分組提交吞吐量，前提是系統負載足夠高，以至於其他事務在給定間隔內準備好提交。但是，它也會透過每次 WAL 重新整理增加延遲，最多可達 commit_delay。由於延遲只有在沒有其他事務準備好提交時才會被浪費，因此只有在即將啟動重新整理時至少有 commit_siblings 個其他事務處於活動狀態時才會執行延遲。此外，如果停用 fsync，則不會執行任何延遲。如果指定此值時不帶單位，則將其視為微秒。預設 commit_delay 為零（無延遲）。只有超級使用者和具有適當 SET 許可權的使用者才能更改此設定。
在 PostgreSQL 9.3 之前的版本中，commit_delay 的行為不同且效果差得多：它隻影響提交，而不是所有 WAL 重新整理，並且即使 WAL 重新整理已提前完成，也會等待整個配置的延遲。從 PostgreSQL 9.3 開始，第一個準備好重新整理的程序會等待配置的間隔，而後續程序只需等待到領導者完成重新整理操作。
commit_siblings (integer) #執行 commit_delay 延遲之前所需的併發開啟事務的最小數量。較大的值會使在延遲間隔內至少有另一個事務準備好提交的可能性更大。預設值為五個事務。
checkpoint_timeout (integer) #自動 WAL 檢查點之間的最大時間。如果指定此值時不帶單位，則將其視為秒。有效範圍在 30 秒到 1 天之間。預設值為五分鐘（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 但小於 OS 的頁面快取時，效能可能會下降。此設定在某些平臺上可能無效。如果指定此值時不帶單位，則將其視為塊，即 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。如果指定此值時不帶單位，則將其視為兆位元組。預設值為 1 GB。增加此引數可能會增加崩潰恢復所需的時間。此引數只能在 postgresql.conf 檔案或伺服器命令列中設定。
min_wal_size (integer) #只要 WAL 磁碟使用量保持在此設定以下，舊 WAL 檔案將在檢查點時始終被迴圈使用，而不是被刪除。這可以確保為應對 WAL 使用量的峰值（例如，在執行大型批處理作業時）保留足夠的 WAL 空間。如果指定此值時不帶單位，則將其視為兆位元組。預設值為 80 MB。此引數只能在 postgresql.conf 檔案或伺服器命令列中設定。
archive_mode (enum) #當 archive_mode 啟用時，透過設定 archive_command 或 archive_library 將已完成的 WAL 段傳送到歸檔儲存。除了 off（停用）之外，還有兩種模式：on 和 always。在正常操作期間，這兩種模式之間沒有區別，但設定為 always 時，WAL 歸檔器在歸檔恢復或備用模式下也啟用。在 always 模式下，從歸檔中恢復的所有檔案或使用流複製流式傳輸的所有檔案將被（再次）歸檔。詳情請參閱第 26.2.9 節。
archive_mode 是一個獨立於 archive_command 和 archive_library 的設定，以便 archive_command 和 archive_library 可以在不離開歸檔模式的情況下進行更改。此引數只能在伺服器啟動時設定。archive_mode 在 wal_level 設定為 minimal 時無法啟用。
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，則會引發錯誤。否則，將使用指定的共享庫進行歸檔。WAL 歸檔程序由 postmaster 在此引數更改時重新啟動。有關更多資訊，請參閱第 25.3.1 節和第 49 章。
此引數只能在 postgresql.conf 檔案或伺服器命令列中設定。
archive_timeout (integer) #僅為已完成的 WAL 段呼叫 archive_command 或 archive_library。因此，如果您的伺服器生成的 WAL 流量很少（或有間歇性流量），則從事務完成到其安全記錄在歸檔儲存中可能需要很長時間。為了限制未歸檔資料的年齡，您可以設定 archive_timeout 以定期強制伺服器切換到新的 WAL 段檔案。當此引數大於零時，伺服器將在自上次段檔案切換以來經過此時間量並且有任何資料庫活動後切換到新段檔案，包括單個檢查點（如果沒有資料庫活動，則跳過檢查點）。請注意，由於強制切換而提前關閉的歸檔檔案仍具有與完全滿的檔案相同的長度。因此，使用非常短的 archive_timeout 是不明智的——它會使您的歸檔儲存膨脹。通常，一分鐘左右的 archive_timeout 設定是合理的。如果您希望資料比這更快地從主伺服器複製，您應該考慮使用流複製而不是歸檔。如果指定此值時不帶單位，則將其視為秒。此引數只能在 postgresql.conf 檔案或伺服器命令列中設定。
本節描述了適用於一般恢復的設定，影響崩潰恢復、流複製和基於歸檔的複製。
recovery_prefetch (enum) #在恢復期間，是否嘗試預取 WAL 中引用的但尚未在緩衝區池中的塊。有效值為 off、on 和 try（預設）。try 設定僅在作業系統支援發出預讀建議時才啟用預取。
預取即將需要的塊可以減少某些工作負載下的恢復期間的 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) #用於檢索 WAL 檔案系列歸檔段的本地 shell 命令。歸檔恢復需要此引數，但流複製是可選的。字串中的任何 %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 的檔案都可以安全地刪除。這些資訊可用於將歸檔截斷到僅支援從當前恢復進行重啟所需的最少內容。對於單備用配置，通常在 archive_cleanup_command 中使用 pg_archivecleanup 模組，例如
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) #此引數指定恢復將進行到的寫入預日誌（write-ahead log）位置的 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）。
通常，您只需要在複雜的多重恢復場景中設定此引數，您需要返回到自身已透過時間點恢復達到的狀態。有關討論，請參閱第 25.3.6 節。
recovery_target_action (enum) #指定伺服器一旦達到恢復目標應採取的操作。預設值為 pause，表示恢復將暫停。promote 表示恢復過程將完成，伺服器將開始接受連線。最後，shutdown 將在達到恢復目標後停止伺服器。
設定 pause 的目的是允許對資料庫執行查詢，以檢查此恢復目標是否是最理想的恢復點。可以透過使用 pg_wal_replay_resume()（參見表 9.99）來恢復暫停狀態，然後恢復將結束。如果此恢復目標不是所需的停止點，則關閉伺服器，將恢復目標設定更改為更晚的目標，然後重新啟動以繼續恢復。
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 彙總器將不會執行。
如果您在文件中看到任何不正確、與特定功能的使用體驗不符或需要進一步澄清的內容，請使用此表格報告文件問題。