|
1 |
| -<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.88 2008/12/11 18:16:18 tgl Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.89 2009/01/16 13:27:23 heikki Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="maintenance">
|
4 | 4 | <title>Routine Database Maintenance Tasks</title>
|
|
367 | 367 | </para>
|
368 | 368 |
|
369 | 369 | <para>
|
370 |
| - <command>VACUUM</>'s behavior is controlled by the configuration parameter |
371 |
| - <xref linkend="guc-vacuum-freeze-min-age">: any XID older than |
372 |
| - <varname>vacuum_freeze_min_age</> transactions is replaced by |
373 |
| - <literal>FrozenXID</>. Larger values of <varname>vacuum_freeze_min_age</> |
| 370 | + <command>VACUUM</>'s behavior is controlled by the two configuration |
| 371 | + parameters: <xref linkend="guc-vacuum-freeze-min-age"> and |
| 372 | + <xref linkend="guc-vacuum-freeze-table-age">. |
| 373 | + <varname>vacuum_freeze_table_age</> controls when <command>VACUUM</> |
| 374 | + performs a full sweep of the table, in order to replace old XID values |
| 375 | + with <literal>FrozenXID</>. <varname>vacuum_freeze_min_age</> |
| 376 | + controls how old an XID value has to be before it's replaced with |
| 377 | + <literal>FrozenXID</>. Larger values of these settings |
374 | 378 | preserve transactional information longer, while smaller values increase
|
375 | 379 | the number of transactions that can elapse before the table must be
|
376 | 380 | vacuumed again.
|
|
379 | 383 | <para>
|
380 | 384 | The maximum time that a table can go unvacuumed is two billion
|
381 | 385 | transactions minus the <varname>vacuum_freeze_min_age</> that was used
|
382 |
| - when it was last vacuumed. If it were to go unvacuumed for longer than |
| 386 | + when <command>VACUUM</> last scanned the whole table. If it were to go |
| 387 | + unvacuumed for longer than |
383 | 388 | that, data loss could result. To ensure that this does not happen,
|
384 | 389 | autovacuum is invoked on any table that might contain XIDs older than the
|
385 | 390 | age specified by the configuration parameter <xref
|
|
403 | 408 | </para>
|
404 | 409 |
|
405 | 410 | <para>
|
406 |
| - The sole disadvantage of increasing <varname>autovacuum_freeze_max_age</> |
| 411 | + The sole disadvantage of increasing <varname>vacuum_freeze_table_age</> |
| 412 | + and <varname>autovacuum_freeze_max_age</> |
407 | 413 | is that the <filename>pg_clog</> subdirectory of the database cluster
|
408 | 414 | will take more space, because it must store the commit status for all
|
409 | 415 | transactions back to the <varname>autovacuum_freeze_max_age</> horizon.
|
410 | 416 | The commit status uses two bits per transaction, so if
|
411 | 417 | <varname>autovacuum_freeze_max_age</> has its maximum allowed value of
|
412 | 418 | a little less than two billion, <filename>pg_clog</> can be expected to
|
413 | 419 | grow to about half a gigabyte. If this is trivial compared to your
|
414 |
| - total database size, setting <varname>autovacuum_freeze_max_age</> to |
415 |
| - its maximum allowed value is recommended. Otherwise, set it depending |
| 420 | + total database size, setting <varname>autovacuum_freeze_max_age</> and |
| 421 | + <varname>vacuum_freeze_table_age</varname> to their maximum allowed values |
| 422 | + is recommended. Otherwise, set them depending |
416 | 423 | on what you are willing to allow for <filename>pg_clog</> storage.
|
417 | 424 | (The default, 200 million transactions, translates to about 50MB of
|
418 | 425 | <filename>pg_clog</> storage.)
|
@@ -455,13 +462,24 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
|
455 | 462 | </programlisting>
|
456 | 463 |
|
457 | 464 | The <literal>age</> column measures the number of transactions from the
|
458 |
| - cutoff XID to the current transaction's XID. Immediately after a |
459 |
| - <command>VACUUM</>, <literal>age(relfrozenxid)</> should be a little |
460 |
| - more than the <varname>vacuum_freeze_min_age</> setting that was used |
461 |
| - (more by the number of transactions started since the <command>VACUUM</> |
462 |
| - started). If <literal>age(relfrozenxid)</> exceeds |
463 |
| - <varname>autovacuum_freeze_max_age</>, an autovacuum will soon be forced |
464 |
| - for the table. |
| 465 | + cutoff XID to the current transaction's XID. When <command>VACUUM</> |
| 466 | + scans the whole table, after it's finished <literal>age(relfrozenxid)</> |
| 467 | + should be a little more than the <varname>vacuum_freeze_min_age</> setting |
| 468 | + that was used (more by the number of transactions started since the |
| 469 | + <command>VACUUM</> started). |
| 470 | + </para> |
| 471 | + |
| 472 | + <para> |
| 473 | + <command>VACUUM</> normally only scans pages that have been modified |
| 474 | + since last vacuum, but <structfield>relfrozenxid</> can only be advanced |
| 475 | + when the whole table is scanned. The whole table is scanned when |
| 476 | + <structfield>relfrozenxid</> is more than |
| 477 | + <varname>vacuum_freeze_table_age</> transactions old, if |
| 478 | + <command>VACUUM FREEZE</> command is used, or if all pages happen to |
| 479 | + require vacuuming to remove dead row versions. If no whole-table-scanning |
| 480 | + <command>VACUUM</> is issued on the table until |
| 481 | + <varname>autovacuum_freeze_max_age</> is reached, an autovacuum will soon |
| 482 | + be forced for the table. |
465 | 483 | </para>
|
466 | 484 |
|
467 | 485 | <para>
|
|