我覺得下面這段文字應該能夠描述清楚 PostgreSQL 的 vacuum.
日常數據庫維護工作 作者：小P
來自： LinuxSir.Org
摘要：爲了保持所安裝的 PostgreSQL 服務器平穩運行, 我們必須做一些日常性的維護工作。我們在這裏討論的這些工作都是經常重複的事情， 可以很容易地使用標準的 Unix 工具，比如cron 腳本來實現;
+++++++++++++++++++++++++++++++++++++++++++
正文
+++++++++++++++++++++++++++++++++++++++++++
- 綜述;
爲了保持所安裝的 PostgreSQL 服務器平穩運行, 我們必須做一些日常性的維護工作。我們在這裏討論的這些工作都是經常重複的事情， 可以很容易地使用標準的 Unix 工具，比如cron 腳本來實現。 不過，設置合適的腳本以及檢查它們是否成功執行則是數據庫管理員的責任， 一件很明顯的維護工作就是經常性地創建數據的備份拷貝。 如果沒有最近的備份，那麼您就沒有從災難中恢復的機會（比如磁盤壞了，失火，誤刪了表等等）。
其它主要的維護範疇的工作包括週期性的 “vacuuming” （清理）數據庫。
其它需要週期性注意的東西是日誌文件的管理。
PostgreSQL 和其它數據庫產品比較起來是低維護量的。 但是，適當在這些任務上放一些注意將更加能夠確保我們的愉快工作和獲取對這個系統富有成效的經驗。 操作環境：PostgreSQL8.2+Ubuntu 7.04 - 日常清理；
2.1 VACUUM;
2.1.1 語法結構；
VACUUM [ FULL | FREEZE ] [ VERBOSE ] [ table ]
VACUUM [ FULL | FREEZE ] [ VERBOSE ] ANALYZE [ table [ (column [, ...] ) ] ]
2.1.2 描述；
VACUUM 回收已刪除元組佔據的存儲空間。 在一般的 PostgreSQL 操作裏， 那些已經 DELETE 的元組或者被 UPDATE 過後過時的元組是沒有從它們所屬的表中物理刪除的； 在完成 VACUUM 之前它們仍然存在。 因此我們有必須週期地運行 VACUUM， 特別是在常更新的表上，如果沒有參數，VACUUM 處理當前數據庫裏每個表， 如果有參數，VACUUM 只處理那個表，簡單的 VACUUM （沒有FULL） 只是簡單地回收空間並且令其可以再次使用；
2.1.3 參數；
FULL --------- 選擇"完全"清理，這樣可以恢復更多的空間， 但是花的時間更多並且在表上施加了排它鎖。
FREEZE --------- 選擇激進的元組"凍結"。
VERBOSE --------- 爲每個表打印一份詳細的清理工作報告。
ANALYZE --------- 更新用於優化器的統計信息，以決定執行查詢的最有效方法。
table --------- 要清理的表的名稱（可以有模式修飾）。缺省時是當前數據庫中的所有表。
column --------- 要分析的具體的列/字段名稱。缺省是所有列/字段。
2.1.4 爲什麼要用VACUUM；
VACUUM命令的含義爲：垃圾收集以及可選地分析一個數據庫。VACUUM回收已刪除元組佔據的存儲空間。在一般的 PostgreSQL 操作裏， 那些已經 DELETE 的元組或者被 UPDATE 過後過時的元組是沒有從它們所屬的表中物理刪除的； 在完成 VACUUM 之前它們仍然存在。 由於以下幾個原因，我們必須週期性運行 PostgreSQL 的 VACUUM 命令∶ 1.恢復那些由已更新的或已刪除的行佔據的磁盤空間。
2.更新 PostgreSQL 查詢規劃器使用的數據統計信息。
3.避免因爲事務 ID 重疊造成的老舊數據的丟失。 對上面每個條件進行 VACUUM 操作的頻率和範圍因不同的節點而不同。 因此，數據庫管理員必須理解這些問題並且開發出合適的維護策略。
建議在經常VACUUM（清理）（至少每晚一次）生產數據庫， 以保證不斷地刪除失效的行。尤其是在增刪了大量記錄之後， 對受影響的表執行 VACUUM ANALYZE 命令是一個很好的習慣。例如：
sir=# VACUUM VERBOSE ANALYZE access ;
信息: 正在清理 (vacuum) "public.access"
信息: index "access_pkey" now contains 0 row versions in 1 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
信息: "access": found 0 removable, 0 nonremovable row versions in 0 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages contain useful free space.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
信息: 正在清理 (vacuum) "pg_toast.pg_toast_16464"
信息: index "pg_toast_16464_index" now contains 0 row versions in 1 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
信息: "pg_toast_16464": found 0 removable, 0 nonremovable row versions in 0 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages contain useful free space.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
信息: 正在分析 "public.access"
信息: "access": scanned 0 of 0 pages, containing 0 live rows and 0 dead rows; 0 rows in sample, 0 estimated total rows
VACUUM
這樣做將更新系統目錄爲最近的更改，並且允許 PostgreSQL 查詢優化器在規劃用戶查詢時有更好的選擇。
不建議日常使用 FULL 選項，但是可以在特殊情況下使用。 一個例子就是在您刪除了一個表的大部分行之後，希望從物理上縮小該表以減少磁盤空間佔用。VACUUM FULL 通常要比單純的 VACUUM 收縮更多表的尺寸;
2.2 恢復磁盤空間;
2.2.1 概述;
在正常的 PostgreSQL 操作裏， 對一行的UPDATE或DELETE並未立即刪除舊版本的數據行。 這個方法對於獲取多版本並行控制的好處是必要的： 如果一個行的版本仍有可能被其它事務看到，那麼您就不能刪除它。 但到了最後，不會有任何事務對過期的或者已經刪除的元組感興趣。 而它佔據的空間必須爲那些新的元組使用而回收， 以避免對磁盤空間增長的無休止的需求。這件事是通過運行 VACUUM 實現的。
很明顯，那些經常更新或者刪除元組的表需要比那些較少更新的表清理的更頻繁一些。 所以，設置一個週期性的 cron 任務 VACUUM 那些選定的表，而忽略那些已經知道變化比較少的表． 這個方法只是在您擁有大量更新頻繁的表和大量很少更新的表的時候有意義 — 清理一個小表的額外開銷根本不值得擔心； VACUUM 命令有兩個變種:
第一種形式，叫做"懶漢 vacuum"或者只是 VACUUM， 在表和索引中標記過期的數據爲將來使用；它並不試圖立即恢復這些過期數據使用的空間。 因此，表文件不會縮小，並且任何文件中沒有使用的空間都不會返回給操作系統。 這個變種的 VACUUM 可以和通常的數據庫操作併發執行;
第二種形式是 VACUUM FULL 命令。 這個形式使用一種更加激進的算法來恢復過期的的行版本佔據的空間。 任何 VACUUM FULL 釋放的空間都立即返回給操作系統。 但是，這個形式的 VACUUM 命令在進行
2.2.2 VACUUM FULL;
VACUUM FULL 一個表的時候在其上要求一個排他鎖。 因此，經常使用 VACUUM FULL 會對併發數據庫查詢有着非常糟糕的影響;
標準形式的 VACUUM 最適合用於維護相當程度的磁盤用量的穩定狀態。 如果您需要把磁盤空間歸還給操作系統，那麼您可以使用 VACUUM FULL — 不過如果釋放的磁盤空間又會很快再次被分配又怎樣？ 如果維護更新頻繁的表，那麼中等頻率的多次標準 VACUUM 運行方法比很低頻率的 VACUUM FULL 更好;
對於大多數節點而言，我們推薦的習慣是在一天中的低使用的時段安排一次整個數據庫的 VACUUM， 必要時外加對更新頻繁的表的更經常的清理。 （有些環境下，對那些更新非常頻繁的表可能會每幾分鐘就 VACUUM 一次。） 如果您的集羣中有多個數據庫，別忘記對每個庫進行清理； vacuumdb腳本可能會幫您的忙;
如果您知道自己剛刪除掉一個表中大部分的行，那麼我們建議使用VACUUM FULL， 這樣該表的穩定態尺寸可以因爲VACUUM FULL更富侵略性的方法而顯著減小。 日常的磁盤空間清理，請使用 VACUUM，而不是 VACUUM FULL;
如果您有一個表，它的內容經常被完全刪除，那麼可以考慮用 TRUNCATE，而不是後面跟着 VACUUM 的 DELETE。 TRUNCATE 立即刪除整個表的內容， 而不要求隨後的 VACUUM 或者VACUUM FULL 來恢復現在沒有用的磁盤空間;
2.3 更新規劃器統計;
PostgreSQL 的查詢規劃器依賴一些有關表內容的統計信息用以爲查詢生成好的規劃。 這些統計是通過ANALYZE 命令獲得的，您可以直接調用這條命令， 也可以把它當做 VACUUM 裏的一個可選步驟來調用。 擁有合理準確的統計是非常重要的，否則，選擇了惡劣的規劃很可能會降低數據庫的性能； 和爲了回收空間做清理一樣，經常更新統計信息也是對更新頻繁的表更有用。 不過，即使是更新非常頻繁的表，如果它的數據的統計分佈並不經常改變，那麼也不需要更新統計信息。 一條簡單的拇指定律就是想想表中字段的最大很最小值改變的幅度。 比如，一個包含行更新時間的 timestamp 字段將是隨着行的追加和更新穩定增長最大值的； 這樣的字段可能需要比那些包含訪問網站的 URL 的字段更頻繁一些更新統計信息。 那些 URL 字段可能改變得一樣頻繁，但是其數值的統計分佈的改變相對要緩慢得多；
我們可以在特定的表，甚至是表中特定的字段上運行 ANALYZE， 所以如果您的應用有需求的話，我們是可以對某些信息更新得比其它信息更頻繁的。 不過，在實際中，這種做法的實用性是值得懷疑的。
ANALYZE 是一項相當快的操作，即時在大表上也很快， 因爲它使用了統計學上的隨機採樣的方法進行行採樣， 而不是把每一行都讀取進來。因此，每隔一段時間對整個數據庫運行一便這條命令可能更簡單； 注： 儘管用 ANALYZE 按字段進行挖掘的方式可能不是很實用， 但您可能還是會發現值得按字段對 ANALYZE 收集的統計信息的詳細級別進行調整。 那些經常在WHERE子句裏使用的字段如果有非常不規則的數據分佈， 那麼就可能需要比其它字段更細緻的數據圖表．
參閱 ALTER TABLE SET STATISTICS．
我們對大多數節點都建議在每天的低使用時段安排一次數據庫範圍的 ANALYZE： 這個任務可以有效地和每天的 VACUUM 組合在一起。 不過，這對那些表統計信息改變相對緩慢的節點可能會過於誇張， 而且少一些的 ANALYZE 也足夠了；
2.4 避免事務 ID 重疊造成的問題;
PostgreSQL 的 MVCC 事務語意依賴於比較事務 ID(XID)的數值： 一條帶有大於當前事務的 XID 的插入 XID 的行版本是"屬於未來的"， 並且不應爲當前事務可見。但是因爲事務 ID 的大小有限（在我們寫這些的時候是 32 位）， 如果一次集羣如果運行的時間很長（大於 4 十億次事務）， 那麼它就要受到事務 ID 重疊的折磨：XID 計數器回到零位， 然後突然間所有以前的事務就變成看上去是在將來的 — 這意味着它們的輸出將變得可見。 簡而言之，可怕的數據丟失，（實際上數據仍然在那裏，但是如果您無法獲取數據，這麼說也只是幸災樂禍。） 在 PostgreSQL 7.2 之前， 防禦 XID 重疊的唯一辦法就是至少每40億事務就重新做一次initdb。 這種做法對高流量的節點而言當然不是令人滿意的做法，所以我們設計了更好的方法。 新的方法允許某個服務器仍然保持運行狀態，不需要 initdb 或者任何類型的重啓。 代價就是下面這樣的維護要求： 數據庫中的每個表都必須在每十億次事務中至少清理一次 ．
從實際角度出發，這個要求不算一個很繁重的要求， 但是因爲如果我們沒能滿足這個要求的後果是全部數據的丟失（而不僅僅是磁盤空間的浪費或者性能的下降）， 我們製作了一些特殊的東西來幫助數據庫管理員避免災難的發生。 對於集羣中的每個數據庫，PostgreSQL 都跟蹤自上次全數據庫範圍 VACUUM 以來的時間。 如果任何數據庫接近了十億次事務的危險級別，系統就開始發出警告信息。 如果什麼都不幹，那麼系統最終會停止正常的操作，直到進行了合適的手工操作。 本節剩下的部分給出這方面的細節。 XID 比較的新方法剝離出兩個特殊的 XID，數字 1 和 2 （BootstrapXID 和 FrozenXID）。 這兩個 XID 總是被認爲表任何普通的 XID 舊。普通的 XID（那些大於 2 的）使用模-231運算進行比較。 這就意味着對於每個普通的 XID，總是有二十億個 XID 是"更舊"以及二十億個 XID"更新"； 表達這個意思的另外一個方法是普通的 XID 空間是沒有終點的環。 因此，一旦一條元組帶着特定的普通 XID 創建出來，那麼該元組 將在以後的二十億次事務中表現得是"在過去"，而不管我們說的是哪個普通 XID。 如果該元組在超過二十億次事務之後仍然存在， 那麼它就會突然變成在將來的元組。爲了避免數據丟失， 老的元組必須在到達二十億次事務的年齡之前的某個時候賦予 XID FrozenXID。 一旦它被賦予了這個特殊的 XID，那麼它們在所有普通事務面前表現爲 “在過去”，而不管事務 ID 是否重疊， 因此這樣的元組直到刪除之前都會完好，不管要保存多長時間．這個 XID 的重新賦值是VACUUM 控制的． VACUUM 的正常策略是給任何其普通 XID 有超過十億次已過去事務行版本重新賦值爲 FrozenXID。 這個策略保留了原來的插入 XID 直到該數值不再令人感興趣爲止。 （實際上，大多數行版本將可能在還沒有"凍結"之前就完成生存和消亡了）。 在這個策略下，任何表在兩次 VACUUM 運行之間的最大的安全間隔是十億次事務： 如果您等的時間更長，那麼最後就可能就會有一條不夠老的行版本在重新賦值時變成比二十億次事務更老， 並因此重疊到了未來 — 也就是說，您失去它了。（當然，它在另外二十億次事務之後會重新出現，不過那樣也無濟於事。）
因爲上面的原因，我們需要週期性地運行 VACUUM， 所以很難有哪個表會到十億次事務還沒有清理過。但是，爲了幫助管理員確保滿足了這個要求， VACUUM 在系統表pg_database 裏存儲了事務 ID 統計。 尤其是一個數據庫的 pg_database 行中的 datfrozenxid 字段在任何數據庫範圍的 VACUUM 操作（也就是沒有聲明任何表的VACUUM）之後將會被更新。 這個字段裏存儲的數值是該 VACUUM 命令使用的凍結終止的 XID。 系統保證在該數據庫中所有比這個終止 XID 老的普通 XID 都被 FrozenXID 代替。 檢查這個信息的一個便利的方法是執行下面的查詢
SELECT datname, age(datfrozenxid) FROM pg_database;
age 字段用於測量從中止 XID 到當前事務的 XID 的數目。
使用了這種標準的凍結策略，對一個剛清理過的數據庫而言， age 字段將從十億處開始。當age到達二十億次的時候， 數據庫必須再次清理以避免事務標識重疊造成的問題。 我們建議的策略是至少每半個十億次（5億次）事務 VACUUM 一次數據庫， 這樣就可以保證足夠的安全邊界範圍．爲了幫助滿足這條規則， 如果有任何 pg_database 記錄顯示出超過15億次事務的 age， 那麼每次數據庫範圍的VACUUM 都會自動發出一條警告，比如：
play=# VACUUM;
WARNING: database "mydb" must be vacuumed within 177009986 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in "mydb".
VACUUM
如果忽略了上面這樣的 VACUUM 信息，如果距離事務 ID 重疊小於 1 千萬次， 那麼 PostgreSQL 就會在每次事務開始前發出類似上面的警告。 如果這些警告還是被忽略了，那麼系統將在距離重疊小於 1 百萬次的時候關閉，並且拒絕執行任何新的事務：
play=# select 2+2;
ERROR: database is shut down to avoid wraparound data loss in database "mydb"
HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb".
這個 1 百萬的事務安全邊界留下來用於讓管理員在不丟失數據的情況下進行恢復， 方法是手工執行所需要的 VACUUM 命令。不過，因爲一旦進入了安全關閉模式，系統就不能再執行命令， 做這件事情的唯一的方法是停止 postmaster，使用一個單獨運行的後端來執行 VACUUM。 關閉模式不會強制於獨立運行的後端。
帶着 FREEZE 選項的 VACUUM 使用了更大膽的凍結策略： 如果行版本已經老得被所有打開的事務看做是良好的， 那麼就都凍結．特別是如果在一個空閒的數據庫上運行 VACUUM FREEZE，那麼就保證該數據庫中所有的行版本都被凍結。 因此，只要該數據庫沒有其它的變化，那麼它就不需要後續的清理以避免事務 ID 重疊問題。 這個技巧被 initdb 用於準備 template0數據庫。 我們也應該用這個方法對所有在 pg_database表裏標記着 datallowconn = false的數據庫進行初始化， 因爲我們還沒有任何便利的方法 VACUUM 一個您無法聯接的數據庫。
2.5 auto-vacuum 守護進程;
從 PostgreSQL 8.1 開始，系統帶有一個額外的可選服務進程， 叫做 autovacuum 守護進程，它的目的是自動執行 VACUUM 和 ANALYZE 命令。在打開這個選項之後，autovacuum 守護進程將週期性運行並且檢查那些有大量插入，更新或者刪除元組操作的表。 這些檢查使用行級別的統計收集設施；因此，除非把 stats row level和 stats row level設置爲 true，否則無法使用 autovacuum 守護。 還有，在爲superuser reserved connections選擇數值的時候，不要忘記給 autovacuum 進程保留一個槽位。 如果打開了 autovacuum 守護，那麼它會每隔autovacumm natime秒鐘運行一次，並且檢查應該處理哪個數據庫。 任何臨近事務 ID 重疊的數據庫都會被立即處理。這個時候，autovacuum 發出一個數據庫範圍的 VACUUM 調用，如果是模板數據庫，則發出 VACUUM FREEZE， 然後終止。如果沒有數據庫複合這個標準，則選擇被上次 autovacuum 處理時間最遠的那個數據庫。 這種情況下，該數據庫裏的表被檢查，然後根據需要發出獨立的 VACUUM 或者 ANALYZE 命令。 對於每個表，用兩個條件來判斷應該使用哪個操作。 如果上次 VACUUM 之後的過期元組的數量超過了"清理閾值（vacuum threshold）"， 那麼就清理改表。清理閾值是定義爲：
清理閾值 = 清理基本閾值 + 清理縮放係數 * 元組數
(vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuples)
這裏的清理基本閾值是autovacuum_vacuum_threshold， 清理的縮放係數是 autovacuum_vacuum_scale_factor， 元組的數目是 失效的元組數目是從統計收集器裏面獲取的；這事一個半精確的計數，由每次 UPDATE 和 DELETE 操作更新。 （它只是半精確的是因爲在重載下，有些信息可能會丟失。） 爲了分析，使用了一個類似的條件：分析閾值，定義爲:
分析閾值 = 分析基本閾值 + 分析縮放係數 * 元組數目
(analyze threshold = analyze base threshold + analyze scale factor * number of tuples)
它會和上次 ANALYZE 插入，更新，或者刪除的元組總數進行比較。
缺省的閾值和伸縮係數是從 postgresql.conf 裏面取得的， 不過，我們可以以每個表獨立設置的方式覆蓋它，方法就是在系統表pg_autovacuum裏輸入記錄。 如果 pg_autovacuum 裏面存在對某個特定表的行，那麼就使用它聲明的設置； 否則使用全局設置。 除了基本閾值和縮放係數之外，在 pg_autovacuum 裏還有三個參數可以爲每個表進行設置。
首先，pg_autovacuum.enabled 可以設置爲 false， 讓 autovacuum 守護進程完全忽略某個表。這種情況下，autovacuum 只有在爲了避免事務 ID 重疊清理整個數據庫的時候纔會動那個表。另外兩個參數，清理開銷延遲 （pg_autovacuum.vac_cost_delay）和清理開銷限制 （pg_autovacuum.vac_cost_limit）， 用於爲基於開銷的清理延遲特性設置表相關的數值。 如果在 pg_autovacuum 裏任何數值設置爲負數， 或者在 pg_autovacuum 裏就根本沒有出現特定表的數據行， 那麼使用 postgresql.conf 裏面對應的數值。
目前沒有任何製作 pg_autovacuum 記錄的支持， 只能手工向該系統表中 INSERT。這個特性將在以後的版本中改進， 並且這個系統表的定義也很有可能會改變。
3. 經常重建索引;
有時候我們值得用REINDEX命令週期的重建索引;
在 PostgreSQL 版本 7.4 之前，我們經常有必要避免"索引膨脹"， 因爲缺乏在 B-tree 索引內部的空間恢復機制。一個情況是就是索引健字的範圍隨着時間而變化 — 比如，一個在某個表的時間戳上的索引，隨着時間的推移，舊的記錄會最終被刪除 — 就會導致膨脹，因爲那些用於不再使用的鍵字範圍的索引頁面不回得到重複使用。 隨着時間的推移，索引的尺寸可能會變得比裏面的有用的數據大得多。
從 PostgreSQL 7.4 開始，那些已經完全清空的索引頁會得到重複使用。 不過這樣仍然會有不充分使用空間的可能：如果一個頁面中大多數索引鍵字被刪除，只留下很少的部分呢， 那麼該頁仍然將被分配。所以，如果使用模式是這樣的：每個範圍裏除了少數鍵字之外，其他大部分鍵字最終都被刪除； 那麼這樣也會導致空間的低效使用。膨脹的可能性不是無窮的 — 最差的情況是每個頁面至少還有一個鍵字 — 但是對這樣的使用模式，我們可能仍然值得安排週期性的重新索引;
對於非 B-tree 索引的膨脹可能還沒有很好地定量分析。 在使用非 B-tree 索引的時候保持對索引的物理尺寸的監控是個很好的主意;
還有，對於 B-tree 索引，一個新建立的索引從某種意義上比更新了多次的訪問起來要快， 因爲在新建立的索引上，邏輯上連接的頁面通常物理上也連接在一起。 （這樣的考慮目前並不適用於非 B-tree 索引。）僅僅從提高訪問速度角度出發， 可能我們也值得週期性的重建索引。
4. 日誌文件維護;
把數據庫服務器的日誌輸出保存在一個地方是個好主意。 在碰到危險的問題的時候，日誌輸出是非常寶貴的。 不過，日誌輸出可能很龐大（特別是在比較高的調試級別上）， 而且您不會無休止地保存它們．您需要"旋轉"日誌文件， 這樣生成新的日誌文件並且經常拋棄老的； 如果您簡單地把postmaster的stderr定向到一個文件中， 您會有日誌輸出， 但是截斷日誌文件的唯一的方法是停止並重起postmaster。 這樣做對於開發環境中使用 PostgreSQL 可能是可以的，但是您肯定不想在生產環境上這麼幹； 一個更好的辦法是把 postmaster 的 stderr （錯誤流 ‘standard error’）輸出發送到某種日誌旋轉程序裏。 我們有一個內置的日誌旋轉程序，您可以通過在 postgresql.conf 裏設置配置參數 redirect_stderr 爲 true 的辦法打開它，終端下輸入：
$ sudo vim /etc/postgresql/8.2/main/postgresql.conf
找到： #redirect_stderr = off 一項，將#號注掉，然後將off改爲on； 另外，您可能會覺得把 postmaster 的stderr 輸出給某些日誌旋轉腳本會更好些，特別是您已經在其它服務器上用了這個程序的時候。 比如，包含在 Apache 發佈裏的 rotatelogs 工具就可以用於 PostgreSQL。 要這麼做，只需要把 postmaster 的 stderr 重定向到指定程序。 如果您用 pg_ctl 啓動服務器，那麼 stderr 已經重定向到 stdout， 因此您只需要一個管道命令，比如：
$ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
另外一種生產級的管理日誌輸出的方法就是把它們發送給 syslog，讓 syslog 處理文件旋轉。 要利用這個工具，我們需要設置 postgresql.conf 裏的 log_destination 配置參數設置爲 syslog （記錄 syslog 日誌）
終端下輸入：
$ sudo vim /etc/postgresql/8.2/main/postgresql.conf
然後修改
#log_destination = ‘stderr’
將stderr改爲syslog; 然後在您想強迫 syslog 守護進程開始寫入一個新日誌文件的時候， 您就可以發送一個 SIGHUP 信號給它。 如果您想自動旋轉日誌文件，那麼我們可以配置 logrotate 程序處理 syslog 的日誌文件。
不過，在很多系統上，syslog 不是非常可靠，特別是在大型日誌信息的情況下； 它可能在您最需要那些信息的時候截斷或者丟棄它們。 還有，在 linux 上，syslog 會把每個消息刷新到磁盤上， 導致很惡劣的性能。 （您可以在 syslog 配置文件裏面的文件名開頭使用一個 - 來關閉這個行爲。）
請注意上面描述的所有解決方案關注的是在可配置的間隔上開始一個新的日誌文件， 它們並沒有處理刪除舊的，不再需要的日誌文件的事情。您可能還需要設置一個批處理，週期地刪除舊日誌文件。 另外一個可能的解法是配置日誌旋轉程序，讓它週期地覆蓋舊的日誌文件。
5. 關於本文;
本文大部分資料都是參照中文文檔，目的是讓兄弟們查找方便一些，詳細的東西在中文文檔都有，多謝各位弟兄們指點 ：）
6. 更新日誌;
7 參考文檔;
《PostgreSQL 8.1 中文文檔》
8. 相關文檔;
《PostgreSQL安裝和簡單使用》
《Postgresql備份和恢復------SQL轉儲篇》
《PostgreSQL的配置文件及用戶權限》
《PostgreSQL數據庫用戶認證》