|
397 | 397 |
|
398 | 398 | <para> |
399 | 399 | The reason that periodic vacuuming solves the problem is that |
400 | | - <productname>PostgreSQL</productname> reserves a special XID |
401 | | - as <literal>FrozenXID</>. This XID does not follow the normal XID |
| 400 | + <command>VACUUM</> will mark rows as <emphasis>frozen</>, indicating that |
| 401 | + they were inserted by a transaction which committed sufficiently far in |
| 402 | + the past that the effects of the inserting transaction is certain to be |
| 403 | + visible, from an MVCC perspective, to all current and future transactions. |
| 404 | + <productname>PostgreSQL</> reserves a special XID, |
| 405 | + <literal>FrozenTransactionId</>, which does not follow the normal XID |
402 | 406 | comparison rules and is always considered older |
403 | 407 | than every normal XID. Normal XIDs are |
404 | 408 | compared using modulo-2<superscript>32</> arithmetic. This means |
|
410 | 414 | the next two billion transactions, no matter which normal XID we are |
411 | 415 | talking about. If the row version still exists after more than two billion |
412 | 416 | transactions, it will suddenly appear to be in the future. To |
413 | | - prevent this, old row versions must be reassigned the XID |
414 | | - <literal>FrozenXID</> sometime before they reach the |
415 | | - two-billion-transactions-old mark. Once they are assigned this |
416 | | - special XID, they will appear to be <quote>in the past</> to all |
417 | | - normal transactions regardless of wraparound issues, and so such |
418 | | - row versions will be valid until deleted, no matter how long that is. |
419 | | - This reassignment of old XIDs is handled by <command>VACUUM</>. |
| 417 | + prevent this, frozen row versions are treated as if the inserting XID were |
| 418 | + <literal>FrozenTransactionId</>, so that they will appear to be |
| 419 | + <quote>in the past</> to all normal transactions regardless of wraparound |
| 420 | + issues, and so such row versions will be valid until deleted, no matter |
| 421 | + how long that is. |
420 | 422 | </para> |
421 | 423 |
|
422 | 424 | <para> |
423 | 425 | <xref linkend="guc-vacuum-freeze-min-age"> |
424 | | - controls how old an XID value has to be before it's replaced with |
425 | | - <literal>FrozenXID</>. Larger values of this setting |
426 | | - preserve transactional information longer, while smaller values increase |
| 426 | + controls how old an XID value has to be before its row version will be |
| 427 | + frozen. Increasing this setting may avoid unnecessary work if the |
| 428 | + rows that would otherwise be frozen will soon be modified again, |
| 429 | + but decreasing this setting increases |
427 | 430 | the number of transactions that can elapse before the table must be |
428 | 431 | vacuumed again. |
429 | 432 | </para> |
430 | 433 |
|
431 | 434 | <para> |
432 | 435 | <command>VACUUM</> normally skips pages that don't have any dead row |
433 | 436 | versions, but those pages might still have row versions with old XID |
434 | | - values. To ensure all oldXIDshave beenreplaced by |
435 | | -<literal>FrozenXID</>, ascan of the whole table is needed. |
| 437 | + values. To ensure all oldrow versionshave beenfrozen, a |
| 438 | + scan of the whole table is needed. |
436 | 439 | <xref linkend="guc-vacuum-freeze-table-age"> controls when |
437 | 440 | <command>VACUUM</> does that: a whole table sweep is forced if |
438 | 441 | the table hasn't been fully scanned for <varname>vacuum_freeze_table_age</> |
|
447 | 450 | the time <command>VACUUM</> last scanned the whole table. If it were to go |
448 | 451 | unvacuumed for longer than |
449 | 452 | that, data loss could result. To ensure that this does not happen, |
450 | | - autovacuum is invoked on any table that might containXIDs older than the |
451 | | - age specified by the configuration parameter <xref |
| 453 | + autovacuum is invoked on any table that might containunfrozen rows with |
| 454 | +XIDs older than theage specified by the configuration parameter <xref |
452 | 455 | linkend="guc-autovacuum-freeze-max-age">. (This will happen even if |
453 | 456 | autovacuum is disabled.) |
454 | 457 | </para> |
|
504 | 507 |
|
505 | 508 | <para> |
506 | 509 | One disadvantage of decreasing <varname>vacuum_freeze_min_age</> is that |
507 | | - it might cause <command>VACUUM</> to do useless work:changing atablerow's |
508 | | -XID to <literal>FrozenXID</> is a waste of time if the row is modified |
| 510 | + it might cause <command>VACUUM</> to do useless work:freezing a row |
| 511 | +version is a waste of time if the row is modified |
509 | 512 | soon thereafter (causing it to acquire a new XID). So the setting should |
510 | 513 | be large enough that rows are not frozen until they are unlikely to change |
511 | | - any more. Another disadvantage of decreasing this setting is |
512 | | - that details about exactly which transaction inserted or modified a |
513 | | - row will be lost sooner. This information sometimes comes in handy, |
514 | | - particularly when trying to analyze what went wrong after a database |
515 | | - failure. For these two reasons, decreasing this setting is not |
516 | | - recommended except for completely static tables. |
| 514 | + any more. |
517 | 515 | </para> |
518 | 516 |
|
519 | 517 | <para> |
520 | | - To track the age of the oldest XIDs in a database, |
| 518 | + To track the age of the oldestunfrozenXIDs in a database, |
521 | 519 | <command>VACUUM</> stores XID |
522 | 520 | statistics in the system tables <structname>pg_class</> and |
523 | 521 | <structname>pg_database</>. In particular, |
524 | 522 | the <structfield>relfrozenxid</> column of a table's |
525 | 523 | <structname>pg_class</> row contains the freeze cutoff XID that was used |
526 | | - by the last whole-table <command>VACUUM</> for that table. Allnormal |
527 | | - XIDs older than this cutoff XID are guaranteed to have been replaced by |
528 | | -<literal>FrozenXID</> within the table. Similarly, |
| 524 | + by the last whole-table <command>VACUUM</> for that table. Allrows |
| 525 | +inserted by transactions withXIDsXIDsolder than this cutoff XID are |
| 526 | +guaranteed to have been frozen. Similarly, |
529 | 527 | the <structfield>datfrozenxid</> column of a database's |
530 | | - <structname>pg_database</> row is a lower bound on thenormal XIDs |
| 528 | + <structname>pg_database</> row is a lower bound on theunfrozen XIDs |
531 | 529 | appearing in that database — it is just the minimum of the |
532 | 530 | per-table <structfield>relfrozenxid</> values within the database. |
533 | 531 | A convenient way to |
|