diff options
| author | Noah Misch <noah@leadboat.com> | 2024-11-25 14:42:35 -0800 |
|---|---|---|
| committer | Noah Misch <noah@leadboat.com> | 2024-11-25 14:42:39 -0800 |
| commit | c1285bbeb962750d9d1aa5e84a6761d7d135146a (patch) | |
| tree | a82dc92dd1048395ca6e927efc839a74827f53d7 /src/backend/jit/llvm/llvmjit_expr.c | |
| parent | 5609b474dba3f8e4874fa8ac08a98f4f00bd063c (diff) | |
| download | postgresql-c1285bbeb962750d9d1aa5e84a6761d7d135146a.tar.gz postgresql-c1285bbeb962750d9d1aa5e84a6761d7d135146a.zip | |
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
Diffstat (limited to 'src/backend/jit/llvm/llvmjit_expr.c')
0 files changed, 0 insertions, 0 deletions