From 0e9d6ea72216b196d37de4629736c0cf34e7cd5c Mon Sep 17 00:00:00 2001 From: John Naylor Date: Sat, 13 May 2023 11:03:40 +0700 Subject: [PATCH v9 3/3] Rough draft of complete steps to recover from (M)XID generation failure TODO: squash with previous --- doc/src/sgml/maintenance.sgml | 61 ++++++++++++++++++++++++++++++++++- 1 file changed, 60 insertions(+), 1 deletion(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 45d6cd1815..fee88cb647 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -675,7 +675,25 @@ HINT: Execute a database-wide VACUUM in that database. In this condition any transactions already in progress can continue, but only read-only transactions can be started. Operations that modify database records or truncate relations will fail. - The VACUUM command can still be run normally to recover. + The VACUUM command can still be run normally. + To restore normal operation: + + + + Commit or rollback any prepared transactions. + + + Terminate any sessions that might have open transactions. + + + Drop any old replication slots. + + + Ensure autovacuum is running, and execute a database-wide VACUUM. + To reduce the time required, it as also possible to issue manual VACUUM + commands on the tables where relminxid is oldest. + + @@ -761,6 +779,47 @@ HINT: Execute a database-wide VACUUM in that database. have the oldest multixact-age. Both of these kinds of aggressive scans will occur even if autovacuum is nominally disabled. + + + Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the + system will begin to emit warning messages like this when the database's + oldest MXIDs reach forty million transactions from the wraparound point: + + +WARNING: database "mydb" must be vacuumed within 39985967 transactions +HINT: To prevent MultiXactId generation failure, execute a database-wide VACUUM in that database. + + + (A manual VACUUM should fix the problem, as suggested by the + hint; but note that the VACUUM must be performed by a + superuser, else it will fail to process system catalogs and thus not + be able to advance the database's datfrozenxid.) + If these warnings are ignored, the system will refuse to generate new + MXIDs once there are fewer than three million left until wraparound: + + +ERROR: database is not accepting commands that generate new MultiXactIds to avoid wraparound data loss in database "mydb" +HINT: Execute a database-wide VACUUM in that database. + + + + + To restore normal operation: + + + Commit or rollback each prepared transaction that might appear in a multixact. + + + Resolve each transaction that might appear in a multixact. + + + Ensure autovacuum is running, and execute a database-wide VACUUM. + To reduce the time required, it as also possible to issue manual VACUUM + commands on the tables where relminmxid is oldest. + + + + -- 2.39.2