Complete TODO item:
* Remove wal_files postgresql.conf option because WAL files are now recycled
This commit is contained in:
Bruce Momjian
parent
fefb57ce74
commit
63653f7ffa
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.129 2002/08/30 00:28:40 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.130 2002/08/30 16:50:49 momjian Exp $
|
||||
-->
|
||||
|
||||
<Chapter Id="runtime">
|
||||
|
|
@ -1949,17 +1949,6 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>WAL_FILES</varname> (<type>integer</type>)</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Number of log files that are created in advance at checkpoint
|
||||
time. This option can only be set at server start or in the
|
||||
<filename>postgresql.conf</filename> file.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>WAL_SYNC_METHOD</varname> (<type>string</type>)</term>
|
||||
<listitem>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v 1.16 2002/07/05 19:06:11 momjian Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v 1.17 2002/08/30 16:50:50 momjian Exp $ -->
|
||||
|
||||
<chapter id="wal">
|
||||
<title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>
|
||||
|
|
@ -276,9 +276,6 @@
|
|||
By default a new 16MB segment file is created only if more than 75% of
|
||||
the current segment has been used. This is inadequate if the system
|
||||
generates more than 4MB of log output between checkpoints.
|
||||
One can instruct the server to pre-create up to 64 log segments
|
||||
at checkpoint time by modifying the <varname>WAL_FILES</varname>
|
||||
configuration parameter.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -306,20 +303,14 @@
|
|||
|
||||
<para>
|
||||
The number of 16MB segment files will always be at least
|
||||
<varname>WAL_FILES</varname> + 1, and will normally not exceed
|
||||
<varname>WAL_FILES</varname> + MAX(<varname>WAL_FILES</varname>,
|
||||
<varname>CHECKPOINT_SEGMENTS</varname>) + 1. This may be used to
|
||||
estimate space requirements for WAL. Ordinarily, when an old log
|
||||
segment files are no longer needed, they are recycled (renamed to
|
||||
become the next sequential future segments). If, due to a short-term
|
||||
peak of log output rate, there are more than
|
||||
<varname>WAL_FILES</varname> + MAX(<varname>WAL_FILES</varname>,
|
||||
<varname>CHECKPOINT_SEGMENTS</varname>) + 1 segment files, then
|
||||
unneeded segment files will be deleted instead of recycled until the
|
||||
system gets back under this limit. (If this happens on a regular
|
||||
basis, <varname>WAL_FILES</varname> should be increased to avoid it.
|
||||
Deleting log segments that will only have to be created again later
|
||||
is expensive and pointless.)
|
||||
1, and will normally not exceed <varname>CHECKPOINT_SEGMENTS</varname>)
|
||||
+ 1. This may be used to estimate space requirements for WAL.
|
||||
Ordinarily, when old log segment files are no longer needed,
|
||||
they are recycled (renamed to become the next sequential future
|
||||
segments). If, due to a short-term peak of log output rate, there
|
||||
are more than <varname>CHECKPOINT_SEGMENTS</varname>) + 1 segment files,
|
||||
the unneeded segment files will be deleted instead of recycled until the
|
||||
system gets back under this limit.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
* Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
|
||||
* Portions Copyright (c) 1994, Regents of the University of California
|
||||
*
|
||||
* $Header: /cvsroot/pgsql/src/backend/access/transam/xlog.c,v 1.102 2002/08/17 15:12:06 momjian Exp $
|
||||
* $Header: /cvsroot/pgsql/src/backend/access/transam/xlog.c,v 1.103 2002/08/30 16:50:50 momjian Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
|
|
@ -87,7 +87,6 @@
|
|||
/* User-settable parameters */
|
||||
int CheckPointSegments = 3;
|
||||
int XLOGbuffers = 8;
|
||||
int XLOGfiles = 0; /* # of files to preallocate during ckpt */
|
||||
int XLOG_DEBUG = 0;
|
||||
char *XLOG_sync_method = NULL;
|
||||
const char XLOG_sync_method_default[] = DEFAULT_SYNC_METHOD_STR;
|
||||
|
|
@ -97,7 +96,7 @@ char XLOG_archive_dir[MAXPGPATH]; /* null string means
|
|||
/*
|
||||
* XLOGfileslop is used in the code as the allowed "fuzz" in the number of
|
||||
* preallocated XLOG segments --- we try to have at least XLOGfiles advance
|
||||
* segments but no more than XLOGfiles+XLOGfileslop segments. This could
|
||||
* segments but no more than XLOGfileslop segments. This could
|
||||
* be made a separate GUC variable, but at present I think it's sufficient
|
||||
* to hardwire it as 2*CheckPointSegments+1. Under normal conditions, a
|
||||
* checkpoint will free no more than 2*CheckPointSegments log segments, and
|
||||
|
|
@ -1422,7 +1421,7 @@ XLogFileInit(uint32 log, uint32 seg,
|
|||
* ours to pre-create a future log segment.
|
||||
*/
|
||||
if (!InstallXLogFileSegment(log, seg, tmppath,
|
||||
*use_existent, XLOGfiles + XLOGfileslop,
|
||||
*use_existent, XLOGfileslop,
|
||||
use_lock))
|
||||
{
|
||||
/* No need for any more future segments... */
|
||||
|
|
@ -1568,20 +1567,9 @@ PreallocXlogFiles(XLogRecPtr endptr)
|
|||
uint32 _logSeg;
|
||||
int lf;
|
||||
bool use_existent;
|
||||
int i;
|
||||
|
||||
XLByteToPrevSeg(endptr, _logId, _logSeg);
|
||||
if (XLOGfiles > 0)
|
||||
{
|
||||
for (i = 1; i <= XLOGfiles; i++)
|
||||
{
|
||||
NextLogSeg(_logId, _logSeg);
|
||||
use_existent = true;
|
||||
lf = XLogFileInit(_logId, _logSeg, &use_existent, true);
|
||||
close(lf);
|
||||
}
|
||||
}
|
||||
else if ((endptr.xrecoff - 1) % XLogSegSize >=
|
||||
if ((endptr.xrecoff - 1) % XLogSegSize >=
|
||||
(uint32) (0.75 * XLogSegSize))
|
||||
{
|
||||
NextLogSeg(_logId, _logSeg);
|
||||
|
|
@ -1635,11 +1623,11 @@ MoveOfflineLogs(uint32 log, uint32 seg, XLogRecPtr endptr)
|
|||
/*
|
||||
* Before deleting the file, see if it can be recycled as
|
||||
* a future log segment. We allow recycling segments up
|
||||
* to XLOGfiles + XLOGfileslop segments beyond the current
|
||||
* to XLOGfileslop segments beyond the current
|
||||
* XLOG location.
|
||||
*/
|
||||
if (InstallXLogFileSegment(endlogId, endlogSeg, path,
|
||||
true, XLOGfiles + XLOGfileslop,
|
||||
true, XLOGfileslop,
|
||||
true))
|
||||
{
|
||||
elog(LOG, "recycled transaction log file %s",
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
* command, configuration file, and command line options.
|
||||
* See src/backend/utils/misc/README for more information.
|
||||
*
|
||||
* $Header: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v 1.87 2002/08/29 21:02:12 momjian Exp $
|
||||
* $Header: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v 1.88 2002/08/30 16:50:50 momjian Exp $
|
||||
*
|
||||
* Copyright 2000 by PostgreSQL Global Development Group
|
||||
* Written by Peter Eisentraut <peter_e@gmx.net>.
|
||||
|
|
@ -640,11 +640,6 @@ static struct config_int
|
|||
8, 4, INT_MAX, NULL, NULL
|
||||
},
|
||||
|
||||
{
|
||||
{ "wal_files", PGC_SIGHUP }, &XLOGfiles,
|
||||
0, 0, 64, NULL, NULL
|
||||
},
|
||||
|
||||
{
|
||||
{ "wal_debug", PGC_SUSET }, &XLOG_DEBUG,
|
||||
0, 0, 16, NULL, NULL
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
* Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
|
||||
* Portions Copyright (c) 1994, Regents of the University of California
|
||||
*
|
||||
* $Id: xlog.h,v 1.35 2002/08/17 15:12:07 momjian Exp $
|
||||
* $Id: xlog.h,v 1.36 2002/08/30 16:50:50 momjian Exp $
|
||||
*/
|
||||
#ifndef XLOG_H
|
||||
#define XLOG_H
|
||||
|
|
@ -185,7 +185,6 @@ extern XLogRecPtr ProcLastRecEnd;
|
|||
/* these variables are GUC parameters related to XLOG */
|
||||
extern int CheckPointSegments;
|
||||
extern int XLOGbuffers;
|
||||
extern int XLOGfiles;
|
||||
extern int XLOG_DEBUG;
|
||||
extern char *XLOG_sync_method;
|
||||
extern const char XLOG_sync_method_default[];
|
||||
|
|
|
|||
Loading…
Reference in New Issue