Update the documentation on recovering from (M)XID exhaustion.
authorRobert Haas <rhaas@postgresql.org>
Mon, 16 Oct 2023 16:57:39 +0000 (12:57 -0400)
committerRobert Haas <rhaas@postgresql.org>
Mon, 16 Oct 2023 16:57:39 +0000 (12:57 -0400)
commita70bce43fbceab6bf0b49498a064c4e87cdbf72f
treee80fe815b5ee96f1fb6b54a95139ffcd47132797
parent5abbd97fef6f18eef91bfed7d2057c39bd204702
Update the documentation on recovering from (M)XID exhaustion.

The old documentation encourages entering single-user mode for no
reason, which is a bad plan in most cases. Instead, discourage users
from doing that, and explain the limited cases in which it may be
desirable.

The old documentation claims that running VACUUM as anyone but the
superuser can't possibly work, which is not really true, because it
might be that some other user has enough permissions to VACUUM all
the tables that matter. Weaken the language just a bit.

The old documentation claims that you can't run any commands
when near XID exhaustion, which is false because you can still
run commands that don't require an XID, like a SELECT without a
locking clause.

The old documentation doesn't clearly explain that it's a good idea
to get rid of prepared transactons, long-running transactions, and
replication 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 in
this type of scenario.

Back-patch to v14. Much of this is good advice on all supported
versions, but before 60f1f09ff44308667ef6c72fbafd68235e55ae27
the chances of VACUUM failing in multi-user mode were much higher.

Alexander Alekseev, John Naylor, Robert Haas, reviewed at various
times by Peter Geoghegan, Hannu Krosing, and Andres Freund.

Discussion: http://postgr.es/m/CA+TgmoYtsUDrzaHcmjFhLzTk1VEv29mO_u-MT+XWHrBJ_4nD8A@mail.gmail.com
doc/src/sgml/maintenance.sgml