|
1 |
| -<!-- $Header: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v 1.14 2001/11/28 20:49:10 petere Exp $ --> |
| 1 | +<!-- $Header: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v 1.15 2002/02/11 23:25:14 momjian Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="wal">
|
4 | 4 | <title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>
|
|
70 | 70 | Problems with indexes (problems 1 and 2) could possibly have been
|
71 | 71 | fixed by additional <function>fsync()</function> calls, but it is
|
72 | 72 | not obvious how to handle the last case without
|
73 |
| - <acronym>WAL</acronym>; <acronym>WAL</acronym> saves the entire |
74 |
| -datapage content in the log if that is required to ensure page |
| 73 | + <acronym>WAL</acronym>; <acronym>WAL</acronym> saves the entire data |
| 74 | + page content in the log if that is required to ensure page |
75 | 75 | consistency for after-crash recovery.
|
76 | 76 | </para>
|
77 | 77 | </sect2>
|
|
85 | 85 | made by aborted transactions will still occupy disk space and that
|
86 | 86 | we still need a permanent <filename>pg_clog</filename> file to hold
|
87 | 87 | the status of transactions, since we are not able to re-use
|
88 |
| - transaction identifiers.Once UNDO is implemented, |
| 88 | + transaction identifiers. Once UNDO is implemented, |
89 | 89 | <filename>pg_clog</filename> will no longer be required to be
|
90 | 90 | permanent; it will be possible to remove
|
91 |
| - <filename>pg_clog</filename> at shutdown.(However, the urgency |
92 |
| -ofthis concern has decreased greatly with the adoption of a segmented |
| 91 | + <filename>pg_clog</filename> at shutdown. (However, the urgency of |
| 92 | + this concern has decreased greatly with the adoption of a segmented |
93 | 93 | storage method for <filename>pg_clog</filename> --- it is no longer
|
94 | 94 | necessary to keep old <filename>pg_clog</filename> entries around
|
95 | 95 | forever.)
|
|
121 | 121 | </para>
|
122 | 122 |
|
123 | 123 | <para>
|
124 |
| - A difficulty standing in the way of realizing these benefits is that they |
125 |
| - require saving <acronym>WAL</acronym> entries for considerable periods |
126 |
| - of time (eg, as long as the longest possible transaction if transaction |
127 |
| - UNDO is wanted).The present <acronym>WAL</acronym> format is |
128 |
| - extremely bulky since it includes many disk page snapshots. |
129 |
| - This is not a serious concern at present, since the entries only need |
130 |
| - to be kept for one or two checkpoint intervals; but to achieve |
131 |
| - these future benefits some sort of compressed <acronym>WAL</acronym> |
132 |
| - format will be needed. |
| 124 | + A difficulty standing in the way of realizing these benefits is that |
| 125 | +theyrequire saving <acronym>WAL</acronym> entries for considerable |
| 126 | +periodsof time (eg, as long as the longest possible transaction if |
| 127 | +transactionUNDO is wanted). The present <acronym>WAL</acronym> |
| 128 | +format isextremely bulky since it includes many disk page |
| 129 | +snapshots.This is not a serious concern at present, since the |
| 130 | +entries only needto be kept for one or two checkpoint intervals; |
| 131 | +but to achievethese future benefits some sort of compressed |
| 132 | +<acronym>WAL</acronym>format will be needed. |
133 | 133 | </para>
|
134 | 134 | </sect2>
|
135 | 135 | </sect1>
|
|
244 | 244 | not occur often enough to prevent <acronym>WAL</acronym> buffers
|
245 | 245 | being written by <function>LogInsert</function>. On such systems
|
246 | 246 | one should increase the number of <acronym>WAL</acronym> buffers by
|
247 |
| - modifying the <varname>WAL_BUFFERS</varname> parameter. The default |
248 |
| - number of <acronym>WAL</acronym> buffers is 8. Increasing this |
249 |
| - value will correspondingly increase shared memory usage. |
| 247 | + modifying the <filename>postgresql.conf</filename> <varname> |
| 248 | + WAL_BUFFERS</varname> parameter. The default number of <acronym> |
| 249 | + WAL</acronym> buffers is 8. Increasing this value will |
| 250 | + correspondingly increase shared memory usage. |
250 | 251 | </para>
|
251 | 252 |
|
252 | 253 | <para>
|
|
293 | 294 |
|
294 | 295 | <para>
|
295 | 296 | Reducing <varname>CHECKPOINT_SEGMENTS</varname> and/or
|
296 |
| - <varname>CHECKPOINT_TIMEOUT</varname> causes checkpoints to be |
297 |
| -donemore often.This allows faster after-crash recovery (since |
298 |
| -less workwill need to be redone).However, one must balance this against |
299 |
| -theincreased cost of flushing dirty data pages more often. In addition, |
300 |
| - to ensure data page consistency, the first modification of a data page |
301 |
| - after each checkpoint results in logging the entire page content. |
302 |
| - Thus a smaller checkpoint interval increases the volume of output to |
303 |
| - the log, partially negating the goal of using a smaller interval, and |
304 |
| - in any case causing more disk I/O. |
| 297 | + <varname>CHECKPOINT_TIMEOUT</varname> causes checkpoints to be done |
| 298 | + more often. This allows faster after-crash recovery (since less work |
| 299 | + will need to be redone). However, one must balance this against the |
| 300 | + increased cost of flushing dirty data pages more often. In addition, |
| 301 | + to ensure data page consistency, the first modification of a data |
| 302 | +pageafter each checkpoint results in logging the entire page |
| 303 | +content.Thus a smaller checkpoint interval increases the volume of |
| 304 | +output tothe log, partially negating the goal of using a smaller |
| 305 | +interval, andin any case causing more disk I/O. |
305 | 306 | </para>
|
306 | 307 |
|
307 | 308 | <para>
|
308 | 309 | The number of 16MB segment files will always be at least
|
309 | 310 | <varname>WAL_FILES</varname> + 1, and will normally not exceed
|
310 |
| - <varname>WAL_FILES</varname> + 2 * <varname>CHECKPOINT_SEGMENTS</varname> |
311 |
| - + 1. This may be used to estimate space requirements for WAL. Ordinarily, |
312 |
| - when an old log segment file is no longer needed, it is recycled (renamed |
313 |
| - to become the next sequential future segment). If, due to a short-term |
314 |
| - peak of log output rate, there are more than <varname>WAL_FILES</varname> + |
315 |
| - 2 * <varname>CHECKPOINT_SEGMENTS</varname> + 1 segment files, then unneeded |
316 |
| - segment files will be deleted instead of recycled until the system gets |
317 |
| - back under this limit. (If this happens on a regular basis, |
318 |
| - <varname>WAL_FILES</varname> should be increased to avoid it. Deleting log |
319 |
| - segments that will only have to be created again later is expensive and |
320 |
| - pointless.) |
| 311 | + <varname>WAL_FILES</varname> + MAX(<varname>WAL_FILES</varname>, |
| 312 | + <varname>CHECKPOINT_SEGMENTS</varname>) + 1. This may be used to |
| 313 | + estimate space requirements for WAL. Ordinarily, when an old log |
| 314 | + segment files are no longer needed, they are recycled (renamed to |
| 315 | + become the next sequential future segments). If, due to a short-term |
| 316 | + peak of log output rate, there are more than |
| 317 | + <varname>WAL_FILES</varname> + MAX(<varname>WAL_FILES</varname>, |
| 318 | + <varname>CHECKPOINT_SEGMENTS</varname>) + 1 segment files, then |
| 319 | + unneeded segment files will be deleted instead of recycled until the |
| 320 | + system gets back under this limit. (If this happens on a regular |
| 321 | + basis, <varname>WAL_FILES</varname> should be increased to avoid it. |
| 322 | + Deleting log segments that will only have to be created again later |
| 323 | + is expensive and pointless.) |
321 | 324 | </para>
|
322 | 325 |
|
323 | 326 | <para>
|
|