Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit0ae5540

Browse files
committed
Update wal files computation documentation.
1 parent028e13b commit0ae5540

File tree

1 file changed

+41
-38
lines changed

1 file changed

+41
-38
lines changed

‎doc/src/sgml/wal.sgml

Lines changed: 41 additions & 38 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
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 $ -->
22

33
<chapter id="wal">
44
<title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>
@@ -70,8 +70,8 @@
7070
Problems with indexes (problems 1 and 2) could possibly have been
7171
fixed by additional <function>fsync()</function> calls, but it is
7272
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
7575
consistency for after-crash recovery.
7676
</para>
7777
</sect2>
@@ -85,11 +85,11 @@
8585
made by aborted transactions will still occupy disk space and that
8686
we still need a permanent <filename>pg_clog</filename> file to hold
8787
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,
8989
<filename>pg_clog</filename> will no longer be required to be
9090
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
9393
storage method for <filename>pg_clog</filename> --- it is no longer
9494
necessary to keep old <filename>pg_clog</filename> entries around
9595
forever.)
@@ -121,15 +121,15 @@
121121
</para>
122122

123123
<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.
133133
</para>
134134
</sect2>
135135
</sect1>
@@ -244,9 +244,10 @@
244244
not occur often enough to prevent <acronym>WAL</acronym> buffers
245245
being written by <function>LogInsert</function>. On such systems
246246
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.
250251
</para>
251252

252253
<para>
@@ -293,31 +294,33 @@
293294

294295
<para>
295296
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.
305306
</para>
306307

307308
<para>
308309
The number of 16MB segment files will always be at least
309310
<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.)
321324
</para>
322325

323326
<para>

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp