1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
5 >Write-Ahead Logging (WAL)</TITLE
8 CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
10 HREF="mailto:pgsql-docs@postgresql.org"><LINK
12 TITLE="PostgreSQL 7.4.1 Documentation"
13 HREF="index.html"><LINK
15 TITLE="Server Administration"
16 HREF="admin.html"><LINK
18 TITLE="Disk Full Failure"
19 HREF="disk-full.html"><LINK
21 TITLE="Future Benefits"
22 HREF="wal-benefits-later.html"><LINK
25 HREF="stylesheet.css"><META
27 CONTENT="2003-12-22T03:48:47"></HEAD
33 SUMMARY="Header navigation table"
43 >PostgreSQL 7.4.1 Documentation</TH
81 HREF="wal-benefits-later.html"
96 >Chapter 25. Write-Ahead Logging (<ACRONYM
105 >Table of Contents</B
109 HREF="wal.html#WAL-BENEFITS-NOW"
110 >Benefits of <ACRONYM
117 HREF="wal-benefits-later.html"
122 HREF="wal-configuration.html"
130 HREF="wal-internals.html"
144 >Write-Ahead Logging</I
149 is a standard approach to transaction logging. Its detailed
150 description may be found in most (if not all) books about
151 transaction processing. Briefly, <ACRONYM
155 concept is that changes to data files (where tables and indexes
156 reside) must be written only after those changes have been logged,
157 that is, when log records have been flushed to permanent
158 storage. If we follow this procedure, we do not need to flush
159 data pages to disk on every transaction commit, because we know
160 that in the event of a crash we will be able to recover the
161 database using the log: any changes that have not been applied to
162 the data pages will first be redone from the log records (this is
163 roll-forward recovery, also known as REDO) and then changes made by
164 uncommitted transactions will be removed from the data pages
165 (roll-backward recovery, UNDO).
172 NAME="WAL-BENEFITS-NOW"
173 >25.1. Benefits of <ACRONYM
182 > The first obvious benefit of using <ACRONYM
186 significantly reduced number of disk writes, since only the log
187 file needs to be flushed to disk at the time of transaction
188 commit; in multiuser environments, commits of many transactions
189 may be accomplished with a single <CODE
193 the log file. Furthermore, the log file is written sequentially,
194 and so the cost of syncing the log is much less than the cost of
195 flushing the data pages.
198 > The next benefit is consistency of the data pages. The truth is
199 that, before <ACRONYM
206 > was never able to guarantee
207 consistency in the case of a crash. Before
211 >, any crash during writing could result in:
219 >index rows pointing to nonexistent table rows</P
223 >index rows lost in split operations</P
227 >totally corrupted table or index page content, because
228 of partially written data pages</P
233 Problems with indexes (problems 1 and 2) could possibly have been
234 fixed by additional <CODE
238 not obvious how to handle the last case without
245 > saves the entire data
246 page content in the log if that is required to ensure page
247 consistency for after-crash recovery.
256 SUMMARY="Footer navigation table"
267 HREF="disk-full.html"
285 HREF="wal-benefits-later.html"
295 >Disk Full Failure</TD