From 72b6098be47e19eff50a052676908e0fde25e7ee Mon Sep 17 00:00:00 2001 From: Michael Paquier Date: Wed, 11 Jan 2023 09:56:14 +0900 Subject: [PATCH] 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 --- src/backend/access/heap/heapam.c | 4 ++++ src/backend/commands/vacuum.c | 21 +++++++++++++++++++-- 2 files changed, 23 insertions(+), 2 deletions(-) diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c index fbe7c222f7..1bd22f9e99 100644 --- 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 5ef6698790..8010a7cd47 100644 --- 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); /*