25.3. 內部

在版本 7.1 以後，WAL 是自動打開的。 除了要求一些磁盤空間存放 WAL日誌以及一些必要的調節以外（參閱Section 25.2）， 對管理員沒有什麼其他要求，

WAL 日誌存放在資料目錄的 pg_xlog 目錄裡，它是作為一個文件段的集合儲存的，通常每個段 16 MB 大。 每個段分割成多個頁，通常 8K 大。日誌記錄頭在 access/xlog.h 裡描述；日誌內容取決於它記錄的事件的類型。 段文件的名字是遞增自然數，從 000000010000000000000000 開始。目前這些數字不能循環使用， 不過要把所有可用的數字都用光也需要非常長的時間。

WAL 的緩衝區和控制結構在共享內存裡， 並且由後端操縱；它們是用輕量的鎖保護的。對共享內存的需求由緩衝區數量決定。 預設的 WAL 緩衝區大小是 8 個 8 KB 的緩衝區，也就是 64KB。

日誌位於和主資料庫文件不同的另外一個磁盤上會比較好。 您可以透過把pg_xlog目錄移動到另外一個位置（ postmaster 當然得關閉）， 然後在 $PGDATA 裡原來的位置建立一個指向新位置的符號鏈接來實現。

WAL 的目的是確保在資料庫記錄被修改之前， 先寫了日誌，但是這個目的有可能被那些向內核謊報成功寫的磁盤驅動器破壞， 這時候，它們實際上只是緩衝了資料而並未把資料儲存到磁盤上。 這種情況下的電源失效仍然可能導致不可恢復的資料崩潰； 管理員應該確保保存 PostgreSQL 的日誌文件的磁盤不會做這種虛假匯報。

在完成一個檢查點並且日誌文件沖刷了之後，檢查點的位置保存在了文件 pg_control 裡。因此在需要做恢復的時候， 後端首先讀取 pg_control 和檢查點記錄； 然後它透過從檢查點記錄裡標識的日誌位置開始向前掃瞄執行 REDO 操作。 因為資料頁的所有內容都保存在檢查點之後的第一個頁面修改的日誌裡， 所以自檢查點以來的所有變化都將被恢復到一個一致的狀態。

但是為了處理 pg_control 可能的損壞， 我們實際上應該實現對現存的日誌段的反向讀取順序 -- 從最新到最老 -- 這樣才能找到最後的檢查點。這些還沒有實現。 pg_control 很小（比一個磁盤頁小），因此它出現只寫了一部分的問題的概率幾乎為零， 到目前為止，我們還沒有看到只是說不能讀取 pg_control 自身的錯誤。 因此，儘管這在理論上是一個薄弱環節，但是 pg_control 看起來似乎並不是實際會發生的問題。