Avoid "you don't own a lock of type ExclusiveLock" in GRANT TABLESPACE.
authorNoah Misch <noah@leadboat.com>
Mon, 25 Nov 2024 22:42:35 +0000 (14:42 -0800)
committerNoah Misch <noah@leadboat.com>
Mon, 25 Nov 2024 22:42:40 +0000 (14:42 -0800)
commit01745fb04d5e910a8f3772469b6015a2beccf027
treed24facd3c7e912a95dc9fc31d6574ce5e7a938a9
parent32057a0f791e865df4ea5cd05ac336ef7e6f99f5
Avoid "you don't own a lock of type ExclusiveLock" in GRANT TABLESPACE.

This WARNING appeared because SearchSysCacheLocked1() read
cc_relisshared before catcache initialization, when the field is false
unconditionally.  On the basis of reading false there, it constructed a
locktag as though pg_tablespace weren't relisshared.  Only shared
catalogs could be affected, and only GRANT TABLESPACE was affected in
practice.  SearchSysCacheLocked1() callers use one other shared-relation
syscache, DATABASEOID.  DATABASEOID is initialized by the end of
CheckMyDatabase(), making the problem unreachable for pg_database.

Back-patch to v13 (all supported versions).  This has no known impact
before v16, where ExecGrant_common() first appeared.  Earlier branches
avoid trouble by having a separate ExecGrant_Tablespace() that doesn't
use LOCKTAG_TUPLE.  However, leaving this unfixed in v15 could ensnare a
future back-patch of a SearchSysCacheLocked1() call.

Reported by Aya Iwata.

Discussion: https://postgr.es/m/OS7PR01MB11964507B5548245A7EE54E70EA212@OS7PR01MB11964.jpnprd01.prod.outlook.com
src/backend/utils/cache/syscache.c
src/test/regress/input/tablespace.source
src/test/regress/output/tablespace.source