108108 </listitem>
109109
110110 <listitem>
111- <simpara>To protect against loss of very old data due to
112- <firstterm>transaction ID wraparound</> or
113- <firstterm>multixact ID wraparound</>.</simpara>
111+ <simpara>To shrink <literal>pg_clog</> and
112+ <literal>pg_multixact</>.</simpara>
114113 </listitem>
115114 </orderedlist>
116115
376375 </sect2>
377376
378377 <sect2 id="vacuum-for-wraparound">
379- <title>Preventing Transaction ID Wraparound Failures </title>
378+ <title>Forced shrinking <literal>pg_clog</> and <literal>pg_multixact</> </title>
380379
381380 <indexterm zone="vacuum-for-wraparound">
382381 <primary>transaction ID</primary>
394393 depend on being able to compare transaction ID (<acronym>XID</>)
395394 numbers: a row version with an insertion XID greater than the current
396395 transaction's XID is <quote>in the future</> and should not be visible
397- to the current transaction. But since transaction IDs have limited size
398- (32 bits) a cluster that runs for a long time (more
396+ to the current transaction. In older versions transaction IDs have
397+ limited size (32 bits), and a cluster that runs for a long time (more
399398 than 4 billion transactions) would suffer <firstterm>transaction ID
400399 wraparound</>: the XID counter wraps around to zero, and all of a sudden
401400 transactions that were in the past appear to be in the future — which
402- means their output become invisible. In short, catastrophic data loss.
403- (Actually the data is still there, but that's cold comfort if you cannot
404- get at it.) To avoid this, it is necessary to vacuum every table
405- in every database at least once every two billion transactions.
401+ means data loss as their output become invisible.
402+ </para>
403+
404+ <para>
405+ <productname>Postgres Pro Enterprise 9.6</productname> introduced
406+ 64-bit transaction IDs, which are not subject to wraparound and
407+ do not need modulo-2<superscript>32</> arithmetic to be compared.
408+ Each tuple header contain two XIDs, so extending them would lead to
409+ high overhead. For that reason on-page XIDs are still 32-bit, but
410+ each page's header contains an offset, called <firstterm>epoch</>,
411+ to which they are added before comparing with each other.
412+ </para>
413+
414+ <para>
415+ When new xid can't fit existing page according to its <firstterm>epoch</>,
416+ those <firstterm>epoch</> is shifted. Single page freeze takes place if
417+ needed. Both actions are performed "on the fly". Page-level wraparound
418+ can happen only when someone holds snapshot which is more than 4 billions
419+ transaction oid.
406420 </para>
407421
408422 <para>
411425 they were inserted by a transaction that committed sufficiently far in
412426 the past that the effects of the inserting transaction are certain to be
413427 visible to all current and future transactions.
414- Normal XIDs are
415- compared using modulo-2<superscript>32</> arithmetic. This means
416- that for every normal XID, there are two billion XIDs that are
417- <quote>older</> and two billion that are <quote>newer</>; another
418- way to say it is that the normal XID space is circular with no
419- endpoint. Therefore, once a row version has been created with a particular
420- normal XID, the row version will appear to be <quote>in the past</> for
421- the next two billion transactions, no matter which normal XID we are
422- talking about. If the row version still exists after more than two billion
423- transactions, it will suddenly appear to be in the future. To
424- prevent this, <productname>PostgreSQL</> reserves a special XID,
425- <literal>FrozenTransactionId</>, which does not follow the normal XID
426- comparison rules and is always considered older
428+ <productname>&productname;</> reserves a special XID,
429+ <literal>FrozenTransactionId</>, which is always considered older
427430 than every normal XID.
428431 Frozen row versions are treated as if the inserting XID were
429432 <literal>FrozenTransactionId</>, so that they will appear to be
430- <quote>in the past</> to all normal transactions regardless of wraparound
431- issues, and so such row versions will be valid until deleted, no matter
432- how long that is.
433+ <quote>in the past</> to all normal transactions.
434+ </para>
435+
436+ <para>
437+ Freezing data by <command>VACUUM</> is not needed anymore for preventing
438+ wraparound, since page-level freeze happens "on the fly". However,
439+ freezing data by <command>VACUUM</> is still needed for shrink
440+ <literal>pg_clog</> and <literal>pg_multixact</>. For historical reasons,
441+ wording "autovacuum to prevent wraparound" is preserved for forced
442+ atuvacuum for shrink <literal>pg_clog</> and <literal>pg_multixact</>.
433443 </para>
434444
435445 <note>
481491 </para>
482492
483493 <para>
484- The maximum time that a table can go unvacuumed is two billion
485- transactions minus the <varname>vacuum_freeze_min_age</> value at
486- the time of the last aggressive vacuum. If it were to go
487- unvacuumed for longer than
488- that, data loss could result. To ensure that this does not happen,
489- autovacuum is invoked on any table that might contain unfrozen rows with
494+ Autovacuum is invoked on any table that might contain unfrozen rows with
490495 XIDs older than the age specified by the configuration parameter <xref
491496 linkend="guc-autovacuum-freeze-max-age">. (This will happen even if
492497 autovacuum is disabled.)
512517 <varname>autovacuum_freeze_max_age</>; a setting higher than that will be
513518 capped to the maximum. A value higher than
514519 <varname>autovacuum_freeze_max_age</> wouldn't make sense because an
515- anti-wraparound autovacuum would be triggered at that point anyway, and
520+ autovacuum to shrink <literal>pg_clog</> and <literal>pg_multixact</>
521+ would be triggered at that point anyway, and
516522 the 0.95 multiplier leaves some breathing room to run a manual
517523 <command>VACUUM</> before that happens. As a rule of thumb,
518524 <command>vacuum_freeze_table_age</> should be set to a value somewhat
519525 below <varname>autovacuum_freeze_max_age</>, leaving enough gap so that
520526 a regularly scheduled <command>VACUUM</> or an autovacuum triggered by
521527 normal delete and update activity is run in that window. Setting it too
522- close could lead to anti-wraparound autovacuums, even though the table
528+ close could lead to autovacuums to to shrink <literal>pg_clog</> and
529+ <literal>pg_multixact</>, even though the table
523530 was recently vacuumed to reclaim space, whereas lower values lead to more
524531 frequent aggressive vacuuming.
525532 </para>
@@ -601,43 +608,8 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
601608 be forced for the table.
602609 </para>
603610
604- <para>
605- If for some reason autovacuum fails to clear old XIDs from a table,
606- the system will begin to emit warning messages like this when the
607- database's oldest XIDs reach ten million transactions from the wraparound
608- point:
609-
610- <programlisting>
611- WARNING: database "mydb" must be vacuumed within 177009986 transactions
612- HINT: To avoid a database shutdown, execute a database-wide VACUUM in "mydb".
613- </programlisting>
614-
615- (A manual <command>VACUUM</> should fix the problem, as suggested by the
616- hint; but note that the <command>VACUUM</> must be performed by a
617- superuser, else it will fail to process system catalogs and thus not
618- be able to advance the database's <structfield>datfrozenxid</>.)
619- If these warnings are
620- ignored, the system will shut down and refuse to start any new
621- transactions once there are fewer than 1 million transactions left
622- until wraparound:
623-
624- <programlisting>
625- ERROR: database is not accepting commands to avoid wraparound data loss in database "mydb"
626- HINT: Stop the postmaster and vacuum that database in single-user mode.
627- </programlisting>
628-
629- The 1-million-transaction safety margin exists to let the
630- administrator recover without data loss, by manually executing the
631- required <command>VACUUM</> commands. However, since the system will not
632- execute commands once it has gone into the safety shutdown mode,
633- the only way to do this is to stop the server and start the server in single-user
634- mode to execute <command>VACUUM</>. The shutdown mode is not enforced
635- in single-user mode. See the <xref linkend="app-postgres"> reference
636- page for details about using single-user mode.
637- </para>
638-
639611 <sect3 id="vacuum-for-multixact-wraparound">
640- <title>Multixacts and Wraparound </title>
612+ <title>Shrinking <literal>pg_multixact</> </title>
641613
642614 <indexterm>
643615 <primary>MultiXactId</primary>
@@ -658,12 +630,12 @@ HINT: Stop the postmaster and vacuum that database in single-user mode.
658630 particular multixact ID is stored separately in
659631 the <filename>pg_multixact</> subdirectory, and only the multixact ID
660632 appears in the <structfield>xmax</> field in the tuple header.
661- Like transaction IDs, multixact IDs are implemented as a
662- 32-bit counter and corresponding storage, all of which requires
663- careful aging management, storage cleanup, and wraparound handling.
633+ Like transaction IDs, multixact IDs are implemented on disk page as a
634+ 64-bit counter with an offset relative to epoch, and corresponding storage,
635+ which requires
636+ careful aging management, and storage cleanup.
664637 There is a separate storage area which holds the list of members in
665- each multixact, which also uses a 32-bit counter and which must also
666- be managed.
638+ each multixact, which uses a 64-bit counter.
667639 </para>
668640
669641 <para>
@@ -691,14 +663,9 @@ HINT: Stop the postmaster and vacuum that database in single-user mode.
691663 </para>
692664
693665 <para>
694- As a safety device, an aggressive vacuum scan will occur for any table
666+ An aggressive vacuum scan will occur for any table
695667 whose multixact-age is greater than
696- <xref linkend="guc-autovacuum-multixact-freeze-max-age">. Aggressive
697- vacuum scans will also occur progressively for all tables, starting with
698- those that have the oldest multixact-age, if the amount of used member
699- storage space exceeds the amount 50% of the addressable storage space.
700- Both of these kinds of aggressive scans will occur even if autovacuum is
701- nominally disabled.
668+ <xref linkend="guc-autovacuum-multixact-freeze-max-age">.
702669 </para>
703670 </sect3>
704671 </sect2>
0 commit comments