git.postgresql.org Git - postgresql.git/commitdiff (original) (raw)

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

*

* 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)

#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"

MultiXactId lastSaneMinMulti;

bool bogus = false;

bool dirty = false;

+ ScanKeyData key[1];

/*

* Restrict this task to one backend per database. This avoids race

/* 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);

/*