Postgres 8.3 正確刪除 pgsql_tmp 中的文件

我們在這裡討論的是 PostgreSQL 8.3 RDBMS。所以，pg_terminate_backend()這個版本不可能。

有時我們必須在作業系統級別 ( kill -9 PID) 終止正在執行的程序來解決與達到的max_connections價值相關的問題。在這種情況下，我們以長時間執行的 SELECT 查詢為目標來殺死。

結果，我們發現我們的文件系統以 98% 的速度增長並迅速填滿，在pgsql_tmp目錄中顯示 1500 多個文件。

一些孤立文件是這種操作的預期結果，因為在處理過程中應刪除臨時文件，proc_exit並且積極終止正在執行的程序不是最佳選擇。

所以，要擺脫這個“垃圾”，我們最好的選擇是什麼：

1. 執行 postmaster 重新啟動，並期望 RDBMS 將自行執行並清除所有臨時目錄；或者
2. 停止 postmaster，手動刪除其中的文件，$PGDATA/pgsql_tmp/然後再次啟動 postmaster；或者
3. 在不停止伺服器的情況下，手動刪除$PGDATA/pgsql_tmp/比目前日期更舊的文件。

請證明你的答案。

與其尋找更好的方法來縫合你的腳，你應該停止射擊自己的腳。

pg_terminate_backend 所做的只是檢查權限，然後發送一個 SIGTERM。您可以直接使用kill -15 PID而不是kill -9 PID. 這將使該程序有機會在退出之前自行清理。更重要的是，它不會不必要地殺死所有其他程序並觸發崩潰恢復。

如果該程序是如此楔入以至於它不會響應kill -15，那麼 pg_terminate_backend 無論如何也無濟於事。在這種情況下，它可能是一個錯誤，使用 EOL 不到 5 年的軟體可能會有所幫助。如果它像那樣被楔入，那麼與其用 殺死它-9，您可能只需用 重新啟動伺服器即可pg_ctl restart -mi。它會完成同樣的事情，但會自己清理文件。

如果您真的只對縫合腳的更好方法感興趣，那麼您的選項 1 應該可以正常工作。選項 2 似乎毫無意義，因為 1 有效。

只要一天足夠長以避免任何仍在執行的程序，您的選項 3 也應該有效。如果您刪除了某個程序仍然需要的文件，那麼最糟糕的情況是該程序會引發錯誤（作為 的使用者，您必須已經習慣了該錯誤kill -9）。我會說這不是“最佳實踐”，但由於您正在執行長期不受支持的軟體並經常使用kill -9，因此最佳實踐船已經航行了。

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