Avoid using tuple from syscache for update of pg_database.datfrozenxid

pg_database.datfrozenxid gets updated using an in-place update at the
end of vacuum or autovacuum.  Since 96cdeae, as pg_database has a toast
relation, it is possible for a pg_database tuple to have toast values
if there is a large set of ACLs in place.  In such a case, the in-place
update would fail because of the flattening of the toast values done for
the catcache entry fetched.  Instead of using a copy from the catcache,
this changes the logic to fetch the copy of the tuple by directly
scanning pg_database.

Note that before 96cdeae, attempting to insert such a tuple to
pg_database would cause a "row is too big" error, so the end-of-vacuum
problem was not reachable.

This issue has been originally fixed in 947789f on v14~, and there have
been reports about this problem on v12 and v13, causing failures at the
end of VACUUM.  This completes the fix on all the stable branches where
pg_database can use a toast table, down to 12.

Author: Ashwin Agrawal, Junfeng Yang
Discussion: https://postgr.es/m/DM5PR0501MB38800D9E4605BCA72DD35557CCE10@DM5PR0501MB3880.namprd05.prod.outlook.com
Discussion: https://postgr.es/m/Y70XNVbUWQsR2Car@paquier.xyz
Backpatch-through: 12

diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index fbe7c222f73b18a9a2b0d96b912c5e686e918496..1bd22f9e996585ffaa675b648be840d7e154224e 100644 (file)
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -5806,6 +5806,10 @@ heap_abort_speculative(Relation relation, ItemPointer tid)
  *
  * tuple is an in-memory tuple structure containing the data to be written
  * over the target tuple.  Also, tuple->t_self identifies the target tuple.
+ *
+ * Note that the tuple updated here had better not come directly from the
+ * syscache if the relation has a toast relation as this tuple could
+ * include toast values that have been expanded, causing a failure here.
  */
 void
 heap_inplace_update(Relation relation, HeapTuple tuple)

diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 5ef6698790c49390ff9b43e2aff4a18a3f4f6f42..8010a7cd470aa311d0e648548d412764591fed66 100644 (file)
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -31,6 +31,7 @@
 #include "access/tableam.h"
 #include "access/transam.h"
 #include "access/xact.h"
+#include "catalog/indexing.h"
 #include "catalog/namespace.h"
 #include "catalog/pg_database.h"
 #include "catalog/pg_inherits.h"
@@ -1343,6 +1344,7 @@ vac_update_datfrozenxid(void)
        MultiXactId lastSaneMinMulti;
        bool            bogus = false;
        bool            dirty = false;
+       ScanKeyData key[1];
 
        /*
         * Restrict this task to one backend per database.  This avoids race
@@ -1460,10 +1462,25 @@ vac_update_datfrozenxid(void)
        /* Now fetch the pg_database tuple we need to update. */
        relation = table_open(DatabaseRelationId, RowExclusiveLock);
 
-       /* Fetch a copy of the tuple to scribble on */
-       tuple = SearchSysCacheCopy1(DATABASEOID, ObjectIdGetDatum(MyDatabaseId));
+       /*
+        * Get the pg_database tuple to scribble on.  Note that this does not
+        * directly rely on the syscache to avoid issues with flattened toast
+        * values for the in-place update.
+        */
+       ScanKeyInit(&key[0],
+                               Anum_pg_database_oid,
+                               BTEqualStrategyNumber, F_OIDEQ,
+                               ObjectIdGetDatum(MyDatabaseId));
+
+       scan = systable_beginscan(relation, DatabaseOidIndexId, true,
+                                                         NULL, 1, key);
+       tuple = systable_getnext(scan);
+       tuple = heap_copytuple(tuple);
+       systable_endscan(scan);
+
        if (!HeapTupleIsValid(tuple))
                elog(ERROR, "could not find tuple for database %u", MyDatabaseId);
+
        dbform = (Form_pg_database) GETSTRUCT(tuple);
 
        /*