mirror of
https://github.com/postgres/postgres.git
synced 2025-11-07 19:06:32 +03:00
Improve table locking behavior in the face of current DDL.
In the previous coding, callers were faced with an awkward choice: look up the name, do permissions checks, and then lock the table; or look up the name, lock the table, and then do permissions checks. The first choice was wrong because the results of the name lookup and permissions checks might be out-of-date by the time the table lock was acquired, while the second allowed a user with no privileges to interfere with access to a table by users who do have privileges (e.g. if a malicious backend queues up for an AccessExclusiveLock on a table on which AccessShareLock is already held, further attempts to access the table will be blocked until the AccessExclusiveLock is obtained and the malicious backend's transaction rolls back). To fix, allow callers of RangeVarGetRelid() to pass a callback which gets executed after performing the name lookup but before acquiring the relation lock. If the name lookup is retried (because invalidation messages are received), the callback will be re-executed as well, so we get the best of both worlds. RangeVarGetRelid() is renamed to RangeVarGetRelidExtended(); callers not wishing to supply a callback can continue to invoke it as RangeVarGetRelid(), which is now a macro. Since the only one caller that uses nowait = true now passes a callback anyway, the RangeVarGetRelid() macro defaults nowait as well. The callback can also be used for supplemental locking - for example, REINDEX INDEX needs to acquire the table lock before the index lock to reduce deadlock possibilities. There's a lot more work to be done here to fix all the cases where this can be a problem, but this commit provides the general infrastructure and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE, LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE. Per discussion with Noah Misch and Alvaro Herrera.
This commit is contained in:
@@ -111,7 +111,6 @@ static void validate_index_heapscan(Relation heapRelation,
|
||||
IndexInfo *indexInfo,
|
||||
Snapshot snapshot,
|
||||
v_i_state *state);
|
||||
static Oid IndexGetRelation(Oid indexId);
|
||||
static bool ReindexIsCurrentlyProcessingIndex(Oid indexOid);
|
||||
static void SetReindexProcessing(Oid heapOid, Oid indexOid);
|
||||
static void ResetReindexProcessing(void);
|
||||
@@ -1301,7 +1300,7 @@ index_drop(Oid indexId)
|
||||
* proceeding until we commit and send out a shared-cache-inval notice
|
||||
* that will make them update their index lists.
|
||||
*/
|
||||
heapId = IndexGetRelation(indexId);
|
||||
heapId = IndexGetRelation(indexId, false);
|
||||
userHeapRelation = heap_open(heapId, AccessExclusiveLock);
|
||||
|
||||
userIndexRelation = index_open(indexId, AccessExclusiveLock);
|
||||
@@ -2763,8 +2762,8 @@ validate_index_heapscan(Relation heapRelation,
|
||||
* IndexGetRelation: given an index's relation OID, get the OID of the
|
||||
* relation it is an index on. Uses the system cache.
|
||||
*/
|
||||
static Oid
|
||||
IndexGetRelation(Oid indexId)
|
||||
Oid
|
||||
IndexGetRelation(Oid indexId, bool missing_ok)
|
||||
{
|
||||
HeapTuple tuple;
|
||||
Form_pg_index index;
|
||||
@@ -2772,7 +2771,11 @@ IndexGetRelation(Oid indexId)
|
||||
|
||||
tuple = SearchSysCache1(INDEXRELID, ObjectIdGetDatum(indexId));
|
||||
if (!HeapTupleIsValid(tuple))
|
||||
{
|
||||
if (missing_ok)
|
||||
return InvalidOid;
|
||||
elog(ERROR, "cache lookup failed for index %u", indexId);
|
||||
}
|
||||
index = (Form_pg_index) GETSTRUCT(tuple);
|
||||
Assert(index->indexrelid == indexId);
|
||||
|
||||
@@ -2800,7 +2803,7 @@ reindex_index(Oid indexId, bool skip_constraint_checks)
|
||||
* Open and lock the parent heap relation. ShareLock is sufficient since
|
||||
* we only need to be sure no schema or data changes are going on.
|
||||
*/
|
||||
heapId = IndexGetRelation(indexId);
|
||||
heapId = IndexGetRelation(indexId, false);
|
||||
heapRelation = heap_open(heapId, ShareLock);
|
||||
|
||||
/*
|
||||
|
||||
Reference in New Issue
Block a user