2007-05-30 21:45:01 +02:00
|
|
|
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.75 2007/05/30 19:45:00 momjian Exp $ -->
|
2001-08-26 23:17:12 +02:00
|
|
|
|
|
|
|
<chapter id="maintenance">
|
|
|
|
<title>Routine Database Maintenance Tasks</title>
|
|
|
|
|
2003-08-31 19:32:24 +02:00
|
|
|
<indexterm zone="maintenance">
|
|
|
|
<primary>maintenance</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
2006-08-01 02:09:06 +02:00
|
|
|
<indexterm zone="maintenance">
|
2006-08-01 21:17:18 +02:00
|
|
|
<primary>routine maintenance</primary>
|
2006-08-01 02:09:06 +02:00
|
|
|
</indexterm>
|
|
|
|
|
2001-08-26 23:17:12 +02:00
|
|
|
<para>
|
2006-08-01 21:17:18 +02:00
|
|
|
<productname>PostgreSQL</>, like any database software, requires that certain tasks
|
|
|
|
be performed regularly to achieve optimum performance. The tasks
|
2006-08-01 02:09:06 +02:00
|
|
|
discussed here are <emphasis>required</emphasis>, but they
|
2006-08-01 21:17:18 +02:00
|
|
|
are repetitive in nature and can easily be automated using standard
|
|
|
|
Unix tools such as <application>cron</application> scripts or
|
|
|
|
Windows' <application>Task Scheduler</>. But it is the database
|
|
|
|
administrator's responsibility to set up appropriate scripts, and to
|
|
|
|
check that they execute successfully.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
2006-08-01 21:17:18 +02:00
|
|
|
|
2001-08-26 23:17:12 +02:00
|
|
|
<para>
|
2006-08-01 21:17:18 +02:00
|
|
|
One obvious maintenance task is creation of backup copies of the data on a
|
|
|
|
regular schedule. Without a recent backup, you have no chance of recovery
|
|
|
|
after a catastrophe (disk failure, fire, mistakenly dropping a critical
|
|
|
|
table, etc.). The backup and recovery mechanisms available in
|
|
|
|
<productname>PostgreSQL</productname> are discussed at length in
|
|
|
|
<xref linkend="backup">.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2006-08-01 21:17:18 +02:00
|
|
|
The other main category of maintenance task is periodic <quote>vacuuming</>
|
|
|
|
of the database. This activity is discussed in
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
<xref linkend="routine-vacuuming">. Closely related to this is updating
|
2006-08-01 21:17:18 +02:00
|
|
|
the statistics that will be used by the query planner, as discussed in
|
|
|
|
<xref linkend="vacuum-for-statistics">.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
2001-09-23 06:06:24 +02:00
|
|
|
<para>
|
2006-08-01 21:17:18 +02:00
|
|
|
Another task that might need periodic attention is log file management.
|
2001-11-20 05:27:49 +01:00
|
|
|
This is discussed in <xref linkend="logfile-maintenance">.
|
2001-09-23 06:06:24 +02:00
|
|
|
</para>
|
2001-08-26 23:17:12 +02:00
|
|
|
|
2006-08-01 21:17:18 +02:00
|
|
|
<para>
|
|
|
|
<productname>PostgreSQL</productname> is low-maintenance compared
|
|
|
|
to some other database management systems. Nonetheless,
|
|
|
|
appropriate attention to these tasks will go far towards ensuring a
|
|
|
|
pleasant and productive experience with the system.
|
|
|
|
</para>
|
2001-08-26 23:17:12 +02:00
|
|
|
|
|
|
|
<sect1 id="routine-vacuuming">
|
|
|
|
<title>Routine Vacuuming</title>
|
|
|
|
|
2001-11-12 20:19:39 +01:00
|
|
|
<indexterm zone="routine-vacuuming">
|
|
|
|
<primary>vacuum</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
2001-08-26 23:17:12 +02:00
|
|
|
<para>
|
2002-06-23 05:37:12 +02:00
|
|
|
<productname>PostgreSQL</productname>'s <command>VACUUM</> command
|
2006-08-01 02:09:06 +02:00
|
|
|
<emphasis>must</emphasis> be run on a regular basis for several reasons:
|
2001-08-26 23:17:12 +02:00
|
|
|
|
|
|
|
<orderedlist>
|
|
|
|
<listitem>
|
2006-08-01 02:09:06 +02:00
|
|
|
<simpara>To recover or reuse disk space occupied by updated or deleted
|
2001-08-26 23:17:12 +02:00
|
|
|
rows.</simpara>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<simpara>To update data statistics used by the
|
|
|
|
<productname>PostgreSQL</productname> query planner.</simpara>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<simpara>To protect against loss of very old data due to
|
|
|
|
<firstterm>transaction ID wraparound</>.</simpara>
|
|
|
|
</listitem>
|
|
|
|
</orderedlist>
|
|
|
|
|
2005-06-13 04:40:08 +02:00
|
|
|
The frequency and scope of the <command>VACUUM</> operations
|
|
|
|
performed for each of these reasons will vary depending on the
|
|
|
|
needs of each site. Therefore, database administrators must
|
|
|
|
understand these issues and develop an appropriate maintenance
|
|
|
|
strategy. This section concentrates on explaining the high-level
|
|
|
|
issues; for details about command syntax and so on, see the <xref
|
|
|
|
linkend="sql-vacuum" endterm="sql-vacuum-title"> reference page.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2006-08-01 21:17:18 +02:00
|
|
|
The standard form of <command>VACUUM</> can run in parallel with production
|
2006-10-23 20:10:32 +02:00
|
|
|
database operations. Commands such as <command>SELECT</command>,
|
|
|
|
<command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command>
|
2006-08-01 02:09:06 +02:00
|
|
|
will continue to function as normal, though you will not be able to modify the
|
2006-10-23 20:10:32 +02:00
|
|
|
definition of a table with commands such as <command>ALTER TABLE ADD COLUMN</command>
|
2006-08-01 21:17:18 +02:00
|
|
|
while it is being vacuumed.
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
Also, <command>VACUUM</command> requires a substantial amount of I/O
|
|
|
|
traffic, which can cause poor performance for other active sessions.
|
|
|
|
There are configuration parameters that can be adjusted to reduce the
|
|
|
|
performance impact of background vacuuming — see
|
2004-12-27 23:30:10 +01:00
|
|
|
<xref linkend="runtime-config-resource-vacuum-cost">.
|
|
|
|
</para>
|
|
|
|
|
2005-09-13 03:51:18 +02:00
|
|
|
<para>
|
|
|
|
An automated mechanism for performing the necessary <command>VACUUM</>
|
|
|
|
operations has been added in <productname>PostgreSQL</productname> 8.1.
|
|
|
|
See <xref linkend="autovacuum">.
|
|
|
|
</para>
|
|
|
|
|
2001-08-26 23:17:12 +02:00
|
|
|
<sect2 id="vacuum-for-space-recovery">
|
|
|
|
<title>Recovering disk space</title>
|
|
|
|
|
2001-11-12 20:19:39 +01:00
|
|
|
<indexterm zone="vacuum-for-space-recovery">
|
|
|
|
<primary>disk space</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
2001-08-26 23:17:12 +02:00
|
|
|
<para>
|
2002-06-23 05:37:12 +02:00
|
|
|
In normal <productname>PostgreSQL</productname> operation, an
|
|
|
|
<command>UPDATE</> or <command>DELETE</> of a row does not
|
2003-11-01 02:56:29 +01:00
|
|
|
immediately remove the old version of the row.
|
2002-06-23 05:37:12 +02:00
|
|
|
This approach is necessary to gain the benefits of multiversion
|
2003-11-01 02:56:29 +01:00
|
|
|
concurrency control (see <xref linkend="mvcc">): the row version
|
2002-06-23 05:37:12 +02:00
|
|
|
must not be deleted while it is still potentially visible to other
|
2003-11-01 02:56:29 +01:00
|
|
|
transactions. But eventually, an outdated or deleted row version is no
|
2002-06-23 05:37:12 +02:00
|
|
|
longer of interest to any transaction. The space it occupies must be
|
2003-11-01 02:56:29 +01:00
|
|
|
reclaimed for reuse by new rows, to avoid infinite growth of disk
|
2002-06-23 05:37:12 +02:00
|
|
|
space requirements. This is done by running <command>VACUUM</>.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Clearly, a table that receives frequent updates or deletes will need
|
2002-06-23 05:37:12 +02:00
|
|
|
to be vacuumed more often than tables that are seldom updated. It
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
might be useful to set up periodic <application>cron</> tasks that
|
2003-12-14 01:10:32 +01:00
|
|
|
<command>VACUUM</command> only selected tables, skipping tables that are known not to
|
2002-06-23 05:37:12 +02:00
|
|
|
change often. This is only likely to be helpful if you have both
|
2004-11-15 07:32:15 +01:00
|
|
|
large heavily-updated tables and large seldom-updated tables — the
|
2002-06-23 05:37:12 +02:00
|
|
|
extra cost of vacuuming a small table isn't enough to be worth
|
|
|
|
worrying about.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2003-12-14 01:10:32 +01:00
|
|
|
There are two variants of the <command>VACUUM</command>
|
|
|
|
command. The first form, known as <quote>lazy vacuum</quote> or
|
2006-12-27 15:55:17 +01:00
|
|
|
just <command>VACUUM</command>, marks dead data in tables and
|
2003-12-14 01:10:32 +01:00
|
|
|
indexes for future reuse; it does <emphasis>not</emphasis> attempt
|
2006-12-27 15:55:17 +01:00
|
|
|
to reclaim the space used by this dead data unless the space is
|
2005-12-07 15:35:45 +01:00
|
|
|
at the end of the table and an exclusive table lock can be easily
|
|
|
|
obtained. Unused space at the start or middle of the file does
|
2005-12-07 06:35:53 +01:00
|
|
|
not result in the file being shortened and space returned to the
|
|
|
|
operating system. This variant of <command>VACUUM</command> can be
|
|
|
|
run concurrently with normal database operations.
|
2003-12-14 01:10:32 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The second form is the <command>VACUUM FULL</command>
|
|
|
|
command. This uses a more aggressive algorithm for reclaiming the
|
2006-12-27 15:55:17 +01:00
|
|
|
space consumed by dead row versions. Any space that is freed by
|
2003-12-14 01:10:32 +01:00
|
|
|
<command>VACUUM FULL</command> is immediately returned to the
|
2007-05-30 21:45:01 +02:00
|
|
|
operating system, and the table data is physically compacted on
|
|
|
|
the disk. Unfortunately, this variant of the
|
2003-12-14 01:10:32 +01:00
|
|
|
<command>VACUUM</command> command acquires an exclusive lock on
|
|
|
|
each table while <command>VACUUM FULL</command> is processing
|
|
|
|
it. Therefore, frequently using <command>VACUUM FULL</command> can
|
|
|
|
have an extremely negative effect on the performance of concurrent
|
|
|
|
database queries.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The standard form of <command>VACUUM</> is best used with the goal
|
|
|
|
of maintaining a fairly level steady-state usage of disk space. If
|
2007-05-30 21:45:01 +02:00
|
|
|
you need to return disk space to the operating system, you can use
|
2004-11-15 07:32:15 +01:00
|
|
|
<command>VACUUM FULL</> — but what's the point of releasing disk
|
2003-12-14 01:10:32 +01:00
|
|
|
space that will only have to be allocated again soon? Moderately
|
|
|
|
frequent standard <command>VACUUM</> runs are a better approach
|
|
|
|
than infrequent <command>VACUUM FULL</> runs for maintaining
|
2007-05-30 21:45:01 +02:00
|
|
|
heavily-updated tables. However, if some heavily-updated tables
|
|
|
|
have gone too long with infrequent <command>VACUUM</>, you can
|
|
|
|
use <command>VACUUM FULL</> or <command>CLUSTER</> to get performance
|
|
|
|
back (it is much slower to scan a table containing almost only dead
|
|
|
|
rows).
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Recommended practice for most sites is to schedule a database-wide
|
2003-12-14 01:10:32 +01:00
|
|
|
<command>VACUUM</> once a day at a low-usage time of day,
|
|
|
|
supplemented by more frequent vacuuming of heavily-updated tables
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
if necessary. (Some installations with extremely high update rates
|
|
|
|
vacuum their busiest tables as often as once every few minutes.)
|
|
|
|
If you have multiple databases
|
2003-12-14 01:10:32 +01:00
|
|
|
in a cluster, don't forget to <command>VACUUM</command> each one;
|
2005-09-23 04:01:35 +02:00
|
|
|
the program <xref linkend="app-vacuumdb" endterm="app-vacuumdb-title">
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
might be helpful.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2003-12-14 01:10:32 +01:00
|
|
|
<command>VACUUM FULL</> is recommended for cases where you know
|
|
|
|
you have deleted the majority of rows in a table, so that the
|
|
|
|
steady-state size of the table can be shrunk substantially with
|
|
|
|
<command>VACUUM FULL</>'s more aggressive approach. Use plain
|
|
|
|
<command>VACUUM</>, not <command>VACUUM FULL</>, for routine
|
|
|
|
vacuuming for space recovery.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2006-08-01 02:09:06 +02:00
|
|
|
If you have a table whose entire contents are deleted on a periodic
|
2006-08-01 21:17:18 +02:00
|
|
|
basis, consider doing it with <command>TRUNCATE</command> rather
|
|
|
|
than using <command>DELETE</command> followed by
|
2003-12-14 01:10:32 +01:00
|
|
|
<command>VACUUM</command>. <command>TRUNCATE</command> removes the
|
2004-12-13 19:05:10 +01:00
|
|
|
entire content of the table immediately, without requiring a
|
2003-12-14 01:10:32 +01:00
|
|
|
subsequent <command>VACUUM</command> or <command>VACUUM
|
|
|
|
FULL</command> to reclaim the now-unused disk space.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2 id="vacuum-for-statistics">
|
|
|
|
<title>Updating planner statistics</title>
|
|
|
|
|
2003-08-31 19:32:24 +02:00
|
|
|
<indexterm zone="vacuum-for-statistics">
|
|
|
|
<primary>statistics</primary>
|
|
|
|
<secondary>of the planner</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<indexterm zone="vacuum-for-statistics">
|
|
|
|
<primary>ANALYZE</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
2001-08-26 23:17:12 +02:00
|
|
|
<para>
|
|
|
|
The <productname>PostgreSQL</productname> query planner relies on
|
|
|
|
statistical information about the contents of tables in order to
|
|
|
|
generate good plans for queries. These statistics are gathered by
|
|
|
|
the <command>ANALYZE</> command, which can be invoked by itself or
|
|
|
|
as an optional step in <command>VACUUM</>. It is important to have
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
reasonably accurate statistics, otherwise poor choices of plans might
|
2001-08-26 23:17:12 +02:00
|
|
|
degrade database performance.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
As with vacuuming for space recovery, frequent updates of statistics
|
2002-06-23 05:37:12 +02:00
|
|
|
are more useful for heavily-updated tables than for seldom-updated
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
ones. But even for a heavily-updated table, there might be no need for
|
2002-06-23 05:37:12 +02:00
|
|
|
statistics updates if the statistical distribution of the data is
|
|
|
|
not changing much. A simple rule of thumb is to think about how much
|
2001-08-26 23:17:12 +02:00
|
|
|
the minimum and maximum values of the columns in the table change.
|
2002-06-23 05:37:12 +02:00
|
|
|
For example, a <type>timestamp</type> column that contains the time
|
|
|
|
of row update will have a constantly-increasing maximum value as
|
|
|
|
rows are added and updated; such a column will probably need more
|
|
|
|
frequent statistics updates than, say, a column containing URLs for
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
pages accessed on a website. The URL column might receive changes just
|
2002-06-23 05:37:12 +02:00
|
|
|
as often, but the statistical distribution of its values probably
|
|
|
|
changes relatively slowly.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
It is possible to run <command>ANALYZE</> on specific tables and even
|
|
|
|
just specific columns of a table, so the flexibility exists to update some
|
|
|
|
statistics more frequently than others if your application requires it.
|
2006-04-23 05:39:52 +02:00
|
|
|
In practice, however, it is usually best to just analyze the entire database
|
|
|
|
because it is a fast operation. It uses a statistical random sampling of
|
|
|
|
the rows of a table rather than reading every single row.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<tip>
|
|
|
|
<para>
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
Although per-column tweaking of <command>ANALYZE</> frequency might not be
|
|
|
|
very productive, you might well find it worthwhile to do per-column
|
2001-08-26 23:17:12 +02:00
|
|
|
adjustment of the level of detail of the statistics collected by
|
2002-11-11 21:14:04 +01:00
|
|
|
<command>ANALYZE</>. Columns that are heavily used in <literal>WHERE</> clauses
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
and have highly irregular data distributions might require a finer-grain
|
2001-08-26 23:17:12 +02:00
|
|
|
data histogram than other columns. See <command>ALTER TABLE SET
|
|
|
|
STATISTICS</>.
|
|
|
|
</para>
|
|
|
|
</tip>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Recommended practice for most sites is to schedule a database-wide
|
|
|
|
<command>ANALYZE</> once a day at a low-usage time of day; this can
|
|
|
|
usefully be combined with a nightly <command>VACUUM</>. However,
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
sites with relatively slowly changing table statistics might find that
|
2001-08-26 23:17:12 +02:00
|
|
|
this is overkill, and that less-frequent <command>ANALYZE</> runs
|
|
|
|
are sufficient.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2 id="vacuum-for-wraparound">
|
|
|
|
<title>Preventing transaction ID wraparound failures</title>
|
|
|
|
|
2001-11-12 20:19:39 +01:00
|
|
|
<indexterm zone="vacuum-for-wraparound">
|
|
|
|
<primary>transaction ID</primary>
|
|
|
|
<secondary>wraparound</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
2001-08-26 23:17:12 +02:00
|
|
|
<para>
|
|
|
|
<productname>PostgreSQL</productname>'s MVCC transaction semantics
|
2003-03-24 15:32:51 +01:00
|
|
|
depend on being able to compare transaction ID (<acronym>XID</>)
|
2003-11-01 02:56:29 +01:00
|
|
|
numbers: a row version with an insertion XID greater than the current
|
2001-08-26 23:17:12 +02:00
|
|
|
transaction's XID is <quote>in the future</> and should not be visible
|
|
|
|
to the current transaction. But since transaction IDs have limited size
|
2003-03-24 15:32:51 +01:00
|
|
|
(32 bits at this writing) a cluster that runs for a long time (more
|
2005-02-20 03:22:07 +01:00
|
|
|
than 4 billion transactions) would suffer <firstterm>transaction ID
|
2001-08-26 23:17:12 +02:00
|
|
|
wraparound</>: the XID counter wraps around to zero, and all of a sudden
|
2004-11-15 07:32:15 +01:00
|
|
|
transactions that were in the past appear to be in the future — which
|
2001-08-28 01:42:34 +02:00
|
|
|
means their outputs become invisible. In short, catastrophic data loss.
|
Wording cleanup for error messages. Also change can't -> cannot.
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
2007-02-01 20:10:30 +01:00
|
|
|
(Actually the data is still there, but that's cold comfort if you cannot
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
get at it.) To avoid this, it is necessary to vacuum every table
|
|
|
|
in every database at least once every two billion transactions.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
The reason that periodic vacuuming solves the problem is that
|
|
|
|
<productname>PostgreSQL</productname> distinguishes a special XID
|
|
|
|
<literal>FrozenXID</>. This XID is always considered older
|
|
|
|
than every normal XID. Normal XIDs are
|
2002-06-23 05:37:12 +02:00
|
|
|
compared using modulo-2<superscript>31</> arithmetic. This means
|
2001-08-26 23:17:12 +02:00
|
|
|
that for every normal XID, there are two billion XIDs that are
|
2002-06-23 05:37:12 +02:00
|
|
|
<quote>older</> and two billion that are <quote>newer</>; another
|
|
|
|
way to say it is that the normal XID space is circular with no
|
2003-11-01 02:56:29 +01:00
|
|
|
endpoint. Therefore, once a row version has been created with a particular
|
|
|
|
normal XID, the row version will appear to be <quote>in the past</> for
|
2002-06-23 05:37:12 +02:00
|
|
|
the next two billion transactions, no matter which normal XID we are
|
2003-11-01 02:56:29 +01:00
|
|
|
talking about. If the row version still exists after more than two billion
|
2002-06-23 05:37:12 +02:00
|
|
|
transactions, it will suddenly appear to be in the future. To
|
2003-11-01 02:56:29 +01:00
|
|
|
prevent data loss, old row versions must be reassigned the XID
|
2002-06-23 05:37:12 +02:00
|
|
|
<literal>FrozenXID</> sometime before they reach the
|
|
|
|
two-billion-transactions-old mark. Once they are assigned this
|
|
|
|
special XID, they will appear to be <quote>in the past</> to all
|
|
|
|
normal transactions regardless of wraparound issues, and so such
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
row versions will be good until deleted, no matter how long that is.
|
|
|
|
This reassignment of old XIDs is handled by <command>VACUUM</>.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<command>VACUUM</>'s behavior is controlled by the configuration parameter
|
|
|
|
<xref linkend="guc-vacuum-freeze-min-age">: any XID older than
|
|
|
|
<varname>vacuum_freeze_min_age</> transactions is replaced by
|
|
|
|
<literal>FrozenXID</>. Larger values of <varname>vacuum_freeze_min_age</>
|
|
|
|
preserve transactional information longer, while smaller values increase
|
|
|
|
the number of transactions that can elapse before the table must be
|
|
|
|
vacuumed again.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The maximum time that a table can go unvacuumed is two billion
|
|
|
|
transactions minus the <varname>vacuum_freeze_min_age</> that was used
|
|
|
|
when it was last vacuumed.
|
|
|
|
If it were to go unvacuumed for longer than that,
|
|
|
|
data loss could result. To ensure that this does not
|
|
|
|
happen, the <firstterm>autovacuum</> facility described in
|
|
|
|
<xref linkend="autovacuum"> is invoked on any table
|
|
|
|
that might contain XIDs older than the age specified by the
|
|
|
|
configuration parameter
|
|
|
|
<xref linkend="guc-autovacuum-freeze-max-age">. (This will happen
|
|
|
|
even if autovacuum is otherwise disabled.)
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
This implies that if a table is not otherwise vacuumed,
|
|
|
|
autovacuum will be invoked on it approximately once every
|
|
|
|
<varname>autovacuum_freeze_max_age</> minus
|
|
|
|
<varname>vacuum_freeze_min_age</> transactions.
|
|
|
|
For tables that are regularly vacuumed for space reclamation purposes,
|
|
|
|
this is of little importance. However, for static tables
|
|
|
|
(including tables that receive inserts, but no updates or deletes),
|
|
|
|
there is no need for vacuuming for space reclamation, and so it can
|
|
|
|
be useful to try to maximize the interval between forced autovacuums
|
|
|
|
on very large static tables. Obviously one can do this either by
|
|
|
|
increasing <varname>autovacuum_freeze_max_age</> or by decreasing
|
|
|
|
<varname>vacuum_freeze_min_age</>.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The sole disadvantage of increasing <varname>autovacuum_freeze_max_age</>
|
|
|
|
is that the <filename>pg_clog</> subdirectory of the database cluster
|
|
|
|
will take more space, because it must store the commit status for all
|
|
|
|
transactions back to the <varname>autovacuum_freeze_max_age</> horizon.
|
|
|
|
The commit status uses two bits per transaction, so if
|
|
|
|
<varname>autovacuum_freeze_max_age</> has its maximum allowed value of
|
|
|
|
a little less than two billion, <filename>pg_clog</> can be expected to
|
|
|
|
grow to about half a gigabyte. If this is trivial compared to your
|
|
|
|
total database size, setting <varname>autovacuum_freeze_max_age</> to
|
|
|
|
its maximum allowed value is recommended. Otherwise, set it depending
|
|
|
|
on what you are willing to allow for <filename>pg_clog</> storage.
|
|
|
|
(The default, 200 million transactions, translates to about 50MB of
|
|
|
|
<filename>pg_clog</> storage.)
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
One disadvantage of decreasing <varname>vacuum_freeze_min_age</> is that
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
it might cause <command>VACUUM</> to do useless work: changing a table row's
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
XID to <literal>FrozenXID</> is a waste of time if the row is modified
|
|
|
|
soon thereafter (causing it to acquire a new XID). So the setting should
|
|
|
|
be large enough that rows are not frozen until they are unlikely to change
|
|
|
|
any more. Another disadvantage of decreasing this setting is
|
|
|
|
that details about exactly which transaction inserted or modified a
|
|
|
|
row will be lost sooner. This information sometimes comes in handy,
|
|
|
|
particularly when trying to analyze what went wrong after a database
|
|
|
|
failure. For these two reasons, decreasing this setting is not
|
|
|
|
recommended except for completely static tables.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
To track the age of the oldest XIDs in a database,
|
|
|
|
<command>VACUUM</> stores XID
|
|
|
|
statistics in the system tables <structname>pg_class</> and
|
|
|
|
<structname>pg_database</>. In particular,
|
|
|
|
the <structfield>relfrozenxid</> column of a table's
|
|
|
|
<structname>pg_class</> row contains the freeze cutoff XID that was used
|
|
|
|
by the last <command>VACUUM</> for that table. All normal
|
2001-08-26 23:17:12 +02:00
|
|
|
XIDs older than this cutoff XID are guaranteed to have been replaced by
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
<literal>FrozenXID</> within the table. Similarly,
|
|
|
|
the <structfield>datfrozenxid</> column of a database's
|
|
|
|
<structname>pg_database</> row is a lower bound on the normal XIDs
|
|
|
|
appearing in that database — it is just the minimum of the
|
|
|
|
per-table <structfield>relfrozenxid</> values within the database.
|
|
|
|
A convenient way to
|
2007-02-01 01:28:19 +01:00
|
|
|
examine this information is to execute queries such as:
|
2002-11-11 21:14:04 +01:00
|
|
|
|
2001-08-26 23:17:12 +02:00
|
|
|
<programlisting>
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
SELECT relname, age(relfrozenxid) FROM pg_class WHERE relkind = 'r';
|
2001-10-13 01:32:34 +02:00
|
|
|
SELECT datname, age(datfrozenxid) FROM pg_database;
|
2001-08-26 23:17:12 +02:00
|
|
|
</programlisting>
|
2002-11-11 21:14:04 +01:00
|
|
|
|
2001-08-26 23:17:12 +02:00
|
|
|
The <literal>age</> column measures the number of transactions from the
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
cutoff XID to the current transaction's XID. Immediately after a
|
|
|
|
<command>VACUUM</>, <literal>age(relfrozenxid)</> should be a little
|
|
|
|
more than the <varname>vacuum_freeze_min_age</> setting that was used
|
|
|
|
(more by the number of transactions started since the <command>VACUUM</>
|
|
|
|
started). If <literal>age(relfrozenxid)</> exceeds
|
|
|
|
<varname>autovacuum_freeze_max_age</>, an autovacuum will soon be forced
|
|
|
|
for the table.
|
2001-08-26 23:17:12 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
If for some reason autovacuum fails to clear old XIDs from a table,
|
|
|
|
the system will begin to emit warning messages like this when the
|
|
|
|
database's oldest XIDs reach ten million transactions from the wraparound
|
|
|
|
point:
|
2002-11-11 21:14:04 +01:00
|
|
|
|
2001-08-26 23:17:12 +02:00
|
|
|
<programlisting>
|
2005-02-20 03:22:07 +01:00
|
|
|
WARNING: database "mydb" must be vacuumed within 177009986 transactions
|
|
|
|
HINT: To avoid a database shutdown, execute a full-database VACUUM in "mydb".
|
2001-08-26 23:17:12 +02:00
|
|
|
</programlisting>
|
|
|
|
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
If these warnings are
|
2005-02-20 03:22:07 +01:00
|
|
|
ignored, the system will shut down and refuse to execute any new
|
|
|
|
transactions once there are fewer than 1 million transactions left
|
|
|
|
until wraparound:
|
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
ERROR: database is shut down to avoid wraparound data loss in database "mydb"
|
|
|
|
HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb".
|
|
|
|
</programlisting>
|
|
|
|
|
|
|
|
The 1-million-transaction safety margin exists to let the
|
|
|
|
administrator recover without data loss, by manually executing the
|
|
|
|
required <command>VACUUM</> commands. However, since the system will not
|
|
|
|
execute commands once it has gone into the safety shutdown mode,
|
2006-06-18 17:38:37 +02:00
|
|
|
the only way to do this is to stop the server and use a single-user
|
2005-02-20 03:22:07 +01:00
|
|
|
backend to execute <command>VACUUM</>. The shutdown mode is not enforced
|
2006-06-18 17:38:37 +02:00
|
|
|
by a single-user backend. See the <xref linkend="app-postgres"> reference
|
|
|
|
page for details about using a single-user backend.
|
2005-02-20 03:22:07 +01:00
|
|
|
</para>
|
|
|
|
|
2001-08-26 23:17:12 +02:00
|
|
|
</sect2>
|
2005-09-13 03:51:18 +02:00
|
|
|
|
|
|
|
<sect2 id="autovacuum">
|
2006-08-29 13:37:47 +02:00
|
|
|
<title id="autovacuum-title">The auto-vacuum daemon</title>
|
2005-09-13 03:51:18 +02:00
|
|
|
|
|
|
|
<indexterm>
|
|
|
|
<primary>autovacuum</primary>
|
|
|
|
<secondary>general information</secondary>
|
|
|
|
</indexterm>
|
|
|
|
<para>
|
2007-04-16 20:30:04 +02:00
|
|
|
Beginning in <productname>PostgreSQL</productname> 8.1, there is an
|
|
|
|
optional feature called <firstterm>autovacuum</firstterm>,
|
|
|
|
whose purpose is to automate the execution of
|
2005-09-13 03:51:18 +02:00
|
|
|
<command>VACUUM</command> and <command>ANALYZE </command> commands.
|
2007-04-16 20:30:04 +02:00
|
|
|
When enabled, autovacuum checks for
|
2005-09-13 03:51:18 +02:00
|
|
|
tables that have had a large number of inserted, updated or deleted
|
|
|
|
tuples. These checks use the row-level statistics collection facility;
|
2007-04-16 20:30:04 +02:00
|
|
|
therefore, autovacuum cannot be used unless <xref
|
2005-09-13 03:51:18 +02:00
|
|
|
linkend="guc-stats-start-collector"> and <xref
|
2007-04-16 20:30:04 +02:00
|
|
|
linkend="guc-stats-row-level"> are set to <literal>true</literal>.
|
|
|
|
In the default configuration, autovacuuming is enabled and the related
|
2007-01-16 19:26:02 +01:00
|
|
|
configuration parameters are appropriately set.
|
2005-09-13 03:51:18 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2007-04-18 22:44:53 +02:00
|
|
|
Beginning in <productname>PostgreSQL</productname> 8.3, autovacuum has a
|
|
|
|
multi-process architecture: there is a daemon process, called the
|
|
|
|
<firstterm>autovacuum launcher</firstterm>, which is in charge of starting
|
|
|
|
an <firstterm>autovacuum worker</firstterm> process on each database every
|
2007-05-15 17:52:40 +02:00
|
|
|
<xref linkend="guc-autovacuum-naptime"> seconds. On each run, the worker
|
|
|
|
process checks each table within that database, and <command>VACUUM</> or
|
|
|
|
<command>ANALYZE</> commands are issued as needed.
|
2007-04-16 20:30:04 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
There is a limit of <xref linkend="guc-autovacuum-max-workers"> worker
|
2007-05-03 17:47:48 +02:00
|
|
|
processes that may be running at any time, so if the <command>VACUUM</>
|
2007-04-16 20:30:04 +02:00
|
|
|
and <command>ANALYZE</> work to do takes too long to run, the deadline may
|
|
|
|
be failed to meet for other databases. Also, if a particular database
|
2007-05-15 17:52:40 +02:00
|
|
|
takes a long time to process, more than one worker may be processing it
|
2007-04-18 22:44:53 +02:00
|
|
|
simultaneously. The workers are smart enough to avoid repeating work that
|
|
|
|
other workers have done, so this is normally not a problem. Note that the
|
|
|
|
number of running workers does not count towards the <xref
|
|
|
|
linkend="guc-max-connections"> nor the <xref
|
|
|
|
linkend="guc-superuser-reserved-connections"> limits.
|
2007-04-16 20:30:04 +02:00
|
|
|
</para>
|
|
|
|
|
2005-09-13 03:51:18 +02:00
|
|
|
<para>
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
Tables whose <structfield>relfrozenxid</> value is more than
|
|
|
|
<varname>autovacuum_freeze_max_age</> transactions old are always
|
|
|
|
vacuumed. Otherwise,
|
|
|
|
two conditions are used to determine which operation(s)
|
2005-10-21 21:39:08 +02:00
|
|
|
to apply. If the number of obsolete tuples since the last
|
2005-09-13 03:51:18 +02:00
|
|
|
<command>VACUUM</command> exceeds the <quote>vacuum threshold</quote>, the
|
2005-10-21 21:39:08 +02:00
|
|
|
table is vacuumed. The vacuum threshold is defined as:
|
2005-09-13 03:51:18 +02:00
|
|
|
<programlisting>
|
|
|
|
vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuples
|
|
|
|
</programlisting>
|
|
|
|
where the vacuum base threshold is
|
2005-10-21 21:39:08 +02:00
|
|
|
<xref linkend="guc-autovacuum-vacuum-threshold">,
|
2005-09-13 03:51:18 +02:00
|
|
|
the vacuum scale factor is
|
2005-10-21 21:39:08 +02:00
|
|
|
<xref linkend="guc-autovacuum-vacuum-scale-factor">,
|
2005-09-13 03:51:18 +02:00
|
|
|
and the number of tuples is
|
|
|
|
<structname>pg_class</structname>.<structfield>reltuples</structfield>.
|
2005-10-21 21:39:08 +02:00
|
|
|
The number of obsolete tuples is obtained from the statistics
|
|
|
|
collector; it is a semi-accurate count updated by each
|
2005-09-13 03:51:18 +02:00
|
|
|
<command>UPDATE</command> and <command>DELETE</command> operation. (It
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
is only semi-accurate because some information might be lost under heavy
|
2007-02-01 01:28:19 +01:00
|
|
|
load.) For analyze, a similar condition is used: the threshold, defined as:
|
2005-10-21 21:39:08 +02:00
|
|
|
<programlisting>
|
|
|
|
analyze threshold = analyze base threshold + analyze scale factor * number of tuples
|
|
|
|
</programlisting>
|
|
|
|
is compared to the total number of tuples inserted, updated, or deleted
|
|
|
|
since the last <command>ANALYZE</command>.
|
2005-09-13 03:51:18 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2005-10-21 21:39:08 +02:00
|
|
|
The default thresholds and scale factors are taken from
|
|
|
|
<filename>postgresql.conf</filename>, but it is possible to override them
|
|
|
|
on a table-by-table basis by making entries in the system catalog
|
|
|
|
<link
|
|
|
|
linkend="catalog-pg-autovacuum"><structname>pg_autovacuum</></link>.
|
|
|
|
If a <structname>pg_autovacuum</structname> row exists for a particular
|
|
|
|
table, the settings it specifies are applied; otherwise the global
|
|
|
|
settings are used. See <xref linkend="runtime-config-autovacuum"> for
|
|
|
|
more details on the global settings.
|
2005-09-13 03:51:18 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
Besides the base threshold values and scale factors, there are five
|
2005-10-21 21:39:08 +02:00
|
|
|
more parameters that can be set for each table in
|
|
|
|
<structname>pg_autovacuum</structname>.
|
|
|
|
The first, <structname>pg_autovacuum</>.<structfield>enabled</>,
|
|
|
|
can be set to <literal>false</literal> to instruct the autovacuum daemon
|
|
|
|
to skip that particular table entirely. In this case
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
autovacuum will only touch the table if it must do so
|
2005-10-21 21:39:08 +02:00
|
|
|
to prevent transaction ID wraparound.
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
The next two parameters, the vacuum cost delay
|
2005-09-13 03:51:18 +02:00
|
|
|
(<structname>pg_autovacuum</structname>.<structfield>vac_cost_delay</structfield>)
|
|
|
|
and the vacuum cost limit
|
2005-09-23 04:01:35 +02:00
|
|
|
(<structname>pg_autovacuum</structname>.<structfield>vac_cost_limit</structfield>),
|
|
|
|
are used to set table-specific values for the
|
2005-09-13 03:51:18 +02:00
|
|
|
<xref linkend="runtime-config-resource-vacuum-cost" endterm="runtime-config-resource-vacuum-cost-title">
|
2005-10-21 21:39:08 +02:00
|
|
|
feature.
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
The last two parameters,
|
|
|
|
(<structname>pg_autovacuum</structname>.<structfield>freeze_min_age</structfield>)
|
|
|
|
and
|
|
|
|
(<structname>pg_autovacuum</structname>.<structfield>freeze_max_age</structfield>),
|
|
|
|
are used to set table-specific values for
|
|
|
|
<xref linkend="guc-vacuum-freeze-min-age"> and
|
|
|
|
<xref linkend="guc-autovacuum-freeze-max-age"> respectively.
|
2005-09-13 03:51:18 +02:00
|
|
|
</para>
|
|
|
|
|
2005-10-21 21:39:08 +02:00
|
|
|
<para>
|
|
|
|
If any of the values in <structname>pg_autovacuum</structname>
|
|
|
|
are set to a negative number, or if a row is not present at all in
|
|
|
|
<structname>pg_autovacuum</structname> for any particular table, the
|
|
|
|
corresponding values from <filename>postgresql.conf</filename> are used.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
There is not currently any support for making
|
|
|
|
<structname>pg_autovacuum</structname> entries, except by doing
|
|
|
|
manual <command>INSERT</>s into the catalog. This feature will be
|
|
|
|
improved in future releases, and it is likely that the catalog
|
|
|
|
definition will change.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<caution>
|
2005-09-16 05:12:32 +02:00
|
|
|
<para>
|
|
|
|
The contents of the <structname>pg_autovacuum</structname> system
|
2007-05-15 17:52:40 +02:00
|
|
|
catalog are currently not saved in database dumps created by the
|
|
|
|
tools <application>pg_dump</> and <application>pg_dumpall</>. If
|
|
|
|
you want to preserve them across a dump/reload cycle, make sure
|
|
|
|
you dump the catalog manually.
|
2005-09-16 05:12:32 +02:00
|
|
|
</para>
|
2005-10-21 21:39:08 +02:00
|
|
|
</caution>
|
2005-09-16 05:12:32 +02:00
|
|
|
|
2007-04-16 20:30:04 +02:00
|
|
|
<para>
|
2007-05-15 17:52:40 +02:00
|
|
|
When multiple workers are running, the cost limit is
|
|
|
|
<quote>balanced</quote> among all the running workers, so that the
|
|
|
|
total impact on the system is the same, regardless of the number
|
|
|
|
of workers actually running.
|
2007-04-16 20:30:04 +02:00
|
|
|
</para>
|
2005-09-13 03:51:18 +02:00
|
|
|
</sect2>
|
2001-08-26 23:17:12 +02:00
|
|
|
</sect1>
|
2001-11-20 05:27:49 +01:00
|
|
|
|
2002-06-13 06:36:50 +02:00
|
|
|
|
2002-06-22 06:08:07 +02:00
|
|
|
<sect1 id="routine-reindex">
|
|
|
|
<title>Routine Reindexing</title>
|
|
|
|
|
|
|
|
<indexterm zone="routine-reindex">
|
|
|
|
<primary>reindex</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<para>
|
2003-09-13 00:17:24 +02:00
|
|
|
In some situations it is worthwhile to rebuild indexes periodically
|
2005-11-01 22:09:51 +01:00
|
|
|
with the <xref linkend="sql-reindex" endterm="sql-reindex-title">
|
|
|
|
command.
|
2005-10-21 21:39:08 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
In <productname>PostgreSQL</> releases before 7.4, periodic reindexing
|
|
|
|
was frequently necessary to avoid <quote>index bloat</>, due to lack of
|
2005-11-05 00:14:02 +01:00
|
|
|
internal space reclamation in B-tree indexes. Any situation in which the
|
2005-10-21 21:39:08 +02:00
|
|
|
range of index keys changed over time — for example, an index on
|
|
|
|
timestamps in a table where old entries are eventually deleted —
|
|
|
|
would result in bloat, because index pages for no-longer-needed portions
|
|
|
|
of the key range were not reclaimed for re-use. Over time, the index size
|
|
|
|
could become indefinitely much larger than the amount of useful data in it.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
In <productname>PostgreSQL</> 7.4 and later, index pages that have become
|
|
|
|
completely empty are reclaimed for re-use. There is still a possibility
|
|
|
|
for inefficient use of space: if all but a few index keys on a page have
|
|
|
|
been deleted, the page remains allocated. So a usage pattern in which all
|
|
|
|
but a few keys in each range are eventually deleted will see poor use of
|
2007-01-31 05:13:22 +01:00
|
|
|
space. For such usage patterns, periodic reindexing is recommended.
|
2005-10-21 21:39:08 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2005-11-05 00:14:02 +01:00
|
|
|
The potential for bloat in non-B-tree indexes has not been well
|
2005-10-21 21:39:08 +02:00
|
|
|
characterized. It is a good idea to keep an eye on the index's physical
|
2005-11-05 00:14:02 +01:00
|
|
|
size when using any non-B-tree index type.
|
2005-10-21 21:39:08 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2005-11-05 00:14:02 +01:00
|
|
|
Also, for B-tree indexes a freshly-constructed index is somewhat faster to
|
2005-10-21 21:39:08 +02:00
|
|
|
access than one that has been updated many times, because logically
|
|
|
|
adjacent pages are usually also physically adjacent in a newly built index.
|
2005-11-05 00:14:02 +01:00
|
|
|
(This consideration does not currently apply to non-B-tree indexes.) It
|
2005-10-21 21:39:08 +02:00
|
|
|
might be worthwhile to reindex periodically just to improve access speed.
|
2002-06-22 06:08:07 +02:00
|
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
2001-11-20 05:27:49 +01:00
|
|
|
<sect1 id="logfile-maintenance">
|
|
|
|
<title>Log File Maintenance</title>
|
|
|
|
|
|
|
|
<indexterm zone="logfile-maintenance">
|
2003-08-31 19:32:24 +02:00
|
|
|
<primary>server log</primary>
|
|
|
|
<secondary>log file maintenance</secondary>
|
2001-11-20 05:27:49 +01:00
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<para>
|
2003-12-14 01:10:32 +01:00
|
|
|
It is a good idea to save the database server's log output
|
|
|
|
somewhere, rather than just routing it to <filename>/dev/null</>.
|
|
|
|
The log output is invaluable when it comes time to diagnose
|
|
|
|
problems. However, the log output tends to be voluminous
|
|
|
|
(especially at higher debug levels) and you won't want to save it
|
|
|
|
indefinitely. You need to <quote>rotate</> the log files so that
|
|
|
|
new log files are started and old ones removed after a reasonable
|
|
|
|
period of time.
|
2001-11-20 05:27:49 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2006-06-18 17:38:37 +02:00
|
|
|
If you simply direct the <systemitem>stderr</> of
|
|
|
|
<command>postgres</command> into a
|
2004-08-06 01:32:13 +02:00
|
|
|
file, you will have log output, but
|
|
|
|
the only way to truncate the log file is to stop and restart
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
the server. This might be OK if you are using
|
2003-12-14 01:10:32 +01:00
|
|
|
<productname>PostgreSQL</productname> in a development environment,
|
|
|
|
but few production servers would find this behavior acceptable.
|
2001-11-20 05:27:49 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2006-06-18 17:38:37 +02:00
|
|
|
A better approach is to send the server's
|
2004-08-06 01:32:13 +02:00
|
|
|
<systemitem>stderr</> output to some type of log rotation program.
|
|
|
|
There is a built-in log rotation program, which you can use by
|
|
|
|
setting the configuration parameter <literal>redirect_stderr</> to
|
|
|
|
<literal>true</> in <filename>postgresql.conf</>. The control
|
|
|
|
parameters for this program are described in <xref
|
|
|
|
linkend="runtime-config-logging-where">.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Alternatively, you might prefer to use an external log rotation
|
|
|
|
program, if you have one that you are already using with other
|
|
|
|
server software. For example, the <application>rotatelogs</application>
|
|
|
|
tool included in the <productname>Apache</productname> distribution
|
|
|
|
can be used with <productname>PostgreSQL</productname>. To do this,
|
2006-06-18 17:38:37 +02:00
|
|
|
just pipe the server's
|
2004-08-06 01:32:13 +02:00
|
|
|
<systemitem>stderr</> output to the desired program.
|
|
|
|
If you start the server with
|
|
|
|
<command>pg_ctl</>, then <systemitem>stderr</>
|
|
|
|
is already redirected to <systemitem>stdout</>, so you just need a
|
2004-12-27 23:30:10 +01:00
|
|
|
pipe command, for example:
|
2004-08-06 01:32:13 +02:00
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
pg_ctl start | rotatelogs /var/log/pgsql_log 86400
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Another production-grade approach to managing log output is to
|
2003-11-01 02:56:29 +01:00
|
|
|
send it all to <application>syslog</> and let
|
|
|
|
<application>syslog</> deal with file rotation. To do this, set the
|
2004-08-06 01:32:13 +02:00
|
|
|
configuration parameter <literal>log_destination</> to <literal>syslog</>
|
|
|
|
(to log to <application>syslog</> only) in
|
|
|
|
<filename>postgresql.conf</>. Then you can send a <literal>SIGHUP</literal>
|
|
|
|
signal to the <application>syslog</> daemon whenever you want to force it
|
|
|
|
to start writing a new log file. If you want to automate log
|
2004-05-16 21:34:46 +02:00
|
|
|
rotation, the <application>logrotate</application> program can be
|
2003-11-01 02:56:29 +01:00
|
|
|
configured to work with log files from
|
|
|
|
<application>syslog</application>.
|
2004-03-15 15:15:45 +01:00
|
|
|
</para>
|
2003-10-09 21:05:09 +02:00
|
|
|
|
2004-03-15 15:15:45 +01:00
|
|
|
<para>
|
|
|
|
On many systems, however, <application>syslog</> is not very reliable,
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
particularly with large log messages; it might truncate or drop messages
|
2004-12-27 23:30:10 +01:00
|
|
|
just when you need them the most. Also, on <productname>Linux</>,
|
2004-03-15 15:21:30 +01:00
|
|
|
<application>syslog</> will sync each message to disk, yielding poor
|
2004-08-06 01:32:13 +02:00
|
|
|
performance. (You can use a <literal>-</> at the start of the file name
|
2004-12-13 19:05:10 +01:00
|
|
|
in the <application>syslog</> configuration file to disable this behavior.)
|
2001-11-20 05:27:49 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2004-08-06 01:32:13 +02:00
|
|
|
Note that all the solutions described above take care of starting new
|
|
|
|
log files at configurable intervals, but they do not handle deletion
|
2004-12-27 23:30:10 +01:00
|
|
|
of old, no-longer-interesting log files. You will probably want to set
|
|
|
|
up a batch job to periodically delete old log files. Another possibility
|
|
|
|
is to configure the rotation program so that old log files are overwritten
|
|
|
|
cyclically.
|
2001-11-20 05:27:49 +01:00
|
|
|
</para>
|
|
|
|
</sect1>
|
2001-08-26 23:17:12 +02:00
|
|
|
</chapter>
|