可以將臨時表空間放在易失性儲存上還是從備份中省略它？（PostgreSQL）

我直覺這很好，但我只想確保從恢復的角度來看沒有問題：

如果我在系統崩潰時失去臨時表空間，這會阻止正確的崩潰恢復嗎？

另外，如果我從基本備份中省略臨時表空間，那會妨礙正確的備份恢復嗎？

如果您指的是 base/pgsql_tmp，那麼您應該沒問題。但我並不是從我自己做過的經驗中說的。唯一的問題是您必須確保在您的 PostgreSQL 伺服器啟動時可以訪問該位置。

（參考：Book PostgreSQL 9.0 High Performance，第 93 頁）。

有問題的書是指在 OS 分區或其他不太“安全”的分區（即非 RAID 等）上創建 base/pgsql_tmp 的 simlink。

這是 PostgreSQL 的官方文件所述：

在PGDATA/base/pgsql_tmp或表空間目錄的 pgsql_tmp 子目錄中創建臨時文件（用於諸如對超出記憶體容量的數據進行排序等操作），如果為它們指定了 pg_default 以外的表空間。臨時文件的名稱格式為 pgsql_tmpPPP.NNN，其中 PPP 是擁有後端的 PID，NNN 區分該後端的不同臨時文件。

參考： 65.1。數據庫文件佈局/ PostgreSQL 文件（目前）

關於備份和恢復，官方文件中沒有關於 pgsql_tmp 目錄的進一步參考。

PostgreSQL 記錄的恢復過程如下：

好的，最糟糕的情況已經發生，您需要從備份中恢復。這是程序：

1. 停止伺服器，如果它正在執行。
2. 如果您有空間這樣做，請將整個集群數據目錄和任何表空間複製到一個臨時位置，以備日後需要它們時使用。請注意，此預防措施將要求您的系統上有足夠的可用空間來保存現有數據庫的兩個副本。如果您沒有足夠的空間，您至少應該保存集群的 pg_xlog 子目錄的內容，因為它可能包含在系統關閉之前未歸檔的日誌。
3. 刪除集群數據目錄下以及您正在使用的任何表空間的根目錄下的所有現有文件和子目錄。
4. 從文件系統備份中恢復數據庫文件。確保以正確的所有權（數據庫系統使用者，而不是 root！）和正確的權限恢復它們。如果您正在使用表空間，您應該驗證 pg_tblspc/ 中的符號連結是否已正確恢復。
5. 刪除 pg_xlog/ 中存在的所有文件；這些來自文件系統備份，因此可能已過時而不是目前。如果您根本沒有歸檔 pg_xlog/，則使用適當的權限重新創建它，如果您之前以這種方式設置它，請注意確保您將其重新建立為符號連結。
6. 如果您在步驟 2 中保存了未歸檔的 WAL 段文件，請將它們複製到 pg_xlog/。（最好是複制它們，而不是移動它們，這樣如果出現問題，你仍然有未修改的文件，你必須重新開始。）
7. 在集群數據目錄中創建一個恢復命令文件 recovery.conf（參見第 27 章）。您可能還想臨時修改 pg_hba.conf 以防止普通使用者連接，直到您確定恢復成功。
8. 啟動伺服器。伺服器將進入恢復模式並繼續讀取它需要的存檔 WAL 文件。如果由於外部錯誤而終止恢復，則可以簡單地重新啟動伺服器並繼續恢復。恢復過程完成後，伺服器會將 recovery.conf 重命名為 recovery.done（以防止以後意外重新進入恢復模式），然後開始正常的數據庫操作。
9. 檢查數據庫的內容以確保您已恢復到所需的狀態。如果沒有，請返回步驟 1。如果一切正常，請通過將 pg_hba.conf 恢復為正常來允許您的使用者連接。

參考： 25.3.4。使用連續存檔備份進行恢復

該目錄將在 PostgreSQL 關閉時被清除，因此 pgsql_tmp 目錄中包含的臨時文件與恢復過程無關。

引用自：https://dba.stackexchange.com/questions/41272