Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit81b3df0

Browse files
committed
Update the documentation on recovering from (M)XID exhaustion.
The old documentation encourages entering single-user mode for noreason, which is a bad plan in most cases. Instead, discourage usersfrom doing that, and explain the limited cases in which it may bedesirable.The old documentation claims that running VACUUM as anyone but thesuperuser can't possibly work, which is not really true, because itmight be that some other user has enough permissions to VACUUM allthe tables that matter. Weaken the language just a bit.The old documentation claims that you can't run any commandswhen near XID exhaustion, which is false because you can stillrun commands that don't require an XID, like a SELECT without alocking clause.The old documentation doesn't clearly explain that it's a good ideato get rid of prepared transactons, long-running transactions, andreplication slots that are preventing (M)XID horizon advancement.Spell out the steps to do that.Also, discourage the use of VACUUM FULL and VACUUM FREEZE inthis type of scenario.Back-patch to v14. Much of this is good advice on all supportedversions, but before60f1f09the chances of VACUUM failing in multi-user mode were much higher.Alexander Alekseev, John Naylor, Robert Haas, reviewed at varioustimes by Peter Geoghegan, Hannu Krosing, and Andres Freund.Discussion:http://postgr.es/m/CA+TgmoYtsUDrzaHcmjFhLzTk1VEv29mO_u-MT+XWHrBJ_4nD8A@mail.gmail.com
1 parentdc75748 commit81b3df0

File tree

1 file changed

+97
-15
lines changed

1 file changed

+97
-15
lines changed

‎doc/src/sgml/maintenance.sgml‎

Lines changed: 97 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -641,29 +641,79 @@ HINT: To avoid a database shutdown, execute a database-wide VACUUM in that data
641641
</programlisting>
642642

643643
(A manual <command>VACUUM</command> should fix the problem, as suggested by the
644-
hint; but note that the <command>VACUUM</command> must be performed by a
645-
superuser, else it will fail to process system catalogs and thus not
646-
be able to advance the database's <structfield>datfrozenxid</structfield>.)
647-
If these warnings are
648-
ignored, the system will shut down and refuse to start any new
649-
transactions once there are fewer than three million transactions left
650-
until wraparound:
644+
hint; but note that the <command>VACUUM</command> should be performed by a
645+
superuser, else it will fail to process system catalogs, which prevent it from
646+
being able to advance the database's <structfield>datfrozenxid</structfield>.)
647+
If these warnings are ignored, the system will refuse to assign new XIDs once
648+
there are fewer than three million transactions left until wraparound:
651649

652650
<programlisting>
653651
ERROR: database is not accepting commands to avoid wraparound data loss in database "mydb"
654652
HINT: Stop the postmaster and vacuum that database in single-user mode.
655653
</programlisting>
656654

657-
The three-million-transaction safety margin exists to let the
658-
administrator recover without data loss, by manually executing the
659-
required <command>VACUUM</command> commands. However, since the system will not
660-
execute commands once it has gone into the safety shutdown mode,
661-
the only way to do this is to stop the server and start the server in single-user
662-
mode to execute <command>VACUUM</command>. The shutdown mode is not enforced
663-
in single-user mode. See the <xref linkend="app-postgres"/> reference
664-
page for details about using single-user mode.
655+
In this condition any transactions already in progress can continue,
656+
but only read-only transactions can be started. Operations that
657+
modify database records or truncate relations will fail.
658+
The <command>VACUUM</command> command can still be run normally.
659+
Contrary to what the hint states, it is not necessary or desirable to stop the
660+
postmaster or enter single user-mode in order to restore normal operation.
661+
Instead, follow these steps:
662+
663+
<orderedlist>
664+
<listitem>
665+
<simpara>Resolve old prepared transactions. You can find these by checking
666+
<link linkend="view-pg-prepared-xacts">pg_prepared_xacts</link> for rows where
667+
<literal>age(transactionid)</literal> is large. Such transactions should be
668+
committed or rolled back.</simpara>
669+
</listitem>
670+
<listitem>
671+
<simpara>End long-running open transactions. You can find these by checking
672+
<link linkend="monitoring-pg-stat-activity-view">pg_stat_activity</link> for rows where
673+
<literal>age(backend_xid)</literal> or <literal>age(backend_xmin)</literal> is
674+
large. Such transactions should be committed or rolled back, or the session
675+
can be terminated using <literal>pg_terminate_backend</literal>.</simpara>
676+
</listitem>
677+
<listitem>
678+
<simpara>Drop any old replication slots. Use
679+
<link linkend="monitoring-pg-stat-replication-view">pg_stat_replication</link> to
680+
find slots where <literal>age(xmin)</literal> or <literal>age(catalog_xmin)</literal>
681+
is large. In many cases, such slots were created for replication to servers that no
682+
longer exist, or that have been down for a long time. If you drop a slot for a server
683+
that still exists and might still try to connect to that slot, that replica may
684+
need to be rebuilt.</simpara>
685+
</listitem>
686+
<listitem>
687+
<simpara>Execute <command>VACUUM</command> in the target database. A database-wide
688+
<literal>VACUUM</literal> is simplest; to reduce the time required, it as also possible
689+
to issue manual <command>VACUUM</command> commands on the tables where
690+
<structfield>relminxid</structfield> is oldest. Do not use <literal>VACUUM FULL</literal>
691+
in this scenario, because it requires an XID and will therefore fail, except in super-user
692+
mode, where it will instead consume an XID and thus increase the risk of transaction ID
693+
wraparound. Do not use <literal>VACUUM FREEZE</literal> either, because it will do
694+
more than the minimum amount of work required to restore normal operation.</simpara>
695+
</listitem>
696+
<listitem>
697+
<simpara>Once normal operation is restored, ensure that autovacuum is properly configured
698+
in the target database in order to avoid future problems.</simpara>
699+
</listitem>
700+
</orderedlist>
665701
</para>
666702

703+
<note>
704+
<para>
705+
In earlier versions, it was sometimes necessary to stop the postmaster and
706+
<command>VACUUM</command> the database in a single-user mode. In typical scenarios, this
707+
is no longer necessary, and should be avoided whenever possible, since it involves taking
708+
the system down. It is also riskier, since it disables transaction ID wraparound safeguards
709+
that are designed to prevent data loss. The only reason to use single-user mode in this
710+
scenario is if you wish to <command>TRUNCATE</command> or <command>DROP</command> unneeded
711+
tables to avoid needing to <command>VACUUM</command> them. The three-million-transaction
712+
safety margin exists to let the administrator do this. See the
713+
<xref linkend="app-postgres"/> reference page for details about using single-user mode.
714+
</para>
715+
</note>
716+
667717
<sect3 id="vacuum-for-multixact-wraparound">
668718
<title>Multixacts and Wraparound</title>
669719

@@ -727,6 +777,38 @@ HINT: Stop the postmaster and vacuum that database in single-user mode.
727777
have the oldest multixact-age. Both of these kinds of aggressive
728778
scans will occur even if autovacuum is nominally disabled.
729779
</para>
780+
781+
<para>
782+
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
783+
system will begin to emit warning messages when the database's oldest MXIDs reach forty
784+
million transactions from the wraparound point. And, just as an the XID case, if these
785+
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
786+
than three million left until wraparound.
787+
</para>
788+
789+
<para>
790+
Normal operation when MXIDs are exhausted can be restored in much the same way as
791+
when XIDs are exhausted. Follow the same steps in the previous section, but with the
792+
following differences:
793+
794+
<orderedlist>
795+
<listitem>
796+
<simpara>Running transactions and prepared transactions can be ignored if there
797+
is no chance that they might appear in a multixact.</simpara>
798+
</listitem>
799+
<listitem>
800+
<simpara>MXID information is not directly visible in system views such as
801+
<literal>pg_stat_activity</literal>; however, looking for old XIDs is still a good
802+
way of determining which transactions are causing MXID wraparound problems.</simpara>
803+
</listitem>
804+
<listitem>
805+
<simpara>XID exhaustion will block all write transactions, but MXID exhaustion will
806+
only block a subset of write transactions, specifically those that involve
807+
row locks that require an MXID.</simpara>
808+
</listitem>
809+
</orderedlist>
810+
</para>
811+
730812
</sect3>
731813
</sect2>
732814

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp