database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-30 06:01:21 +03:00
Code Activity

Fix inconsistencies and typos in the tree

Browse Source 
This is numbered take 7, and addresses a set of issues around:
- Fixes for typos and incorrect reference names.
- Removal of unneeded comments.
- Removal of unreferenced functions and structures.
- Fixes regarding variable name consistency.

Author: Alexander Lakhin
Discussion: https://postgr.es/m/10bfd4ac-3e7c-40ab-2b2e-355ed15495e8@gmail.com
This commit is contained in:
Michael Paquier
2019-07-16 13:23:53 +09:00
parent 4c3d05d875
commit 0896ae561b
41 changed files with 55 additions and 84 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
src/backend/storage/lmgr/lock.c
View File

@@ -216,9 +216,9 @@ static PROCLOCK *FastPathGetRelationLockEntry(LOCALLOCK *locallock);
/*
* To make the fast-path lock mechanism work, we must have some way of
* preventing the use of the fast-path when a conflicting lock might be
* present. We partition* the locktag space into FAST_PATH_HASH_BUCKETS
* partitions, and maintain an integer count of the number of "strong" lockers
* preventing the use of the fast-path when a conflicting lock might be present.
* We partition* the locktag space into FAST_PATH_STRONG_LOCK_HASH_PARTITIONS,
* and maintain an integer count of the number of "strong" lockers
* in each partition. When any "strong" lockers are present (which is
* hopefully not very often), the fast-path mechanism can't be used, and we
* must fall back to the slower method of pushing matching locks directly
@@ -2709,7 +2709,7 @@ FastPathTransferRelationLocks(LockMethod lockMethodTable, const LOCKTAG *locktag
}
/*
* FastPathGetLockEntry
* FastPathGetRelationLockEntry
* Return the PROCLOCK for a lock originally taken via the fast-path,
* transferring it to the primary lock table if necessary.
*
@@ -2896,8 +2896,8 @@ GetLockConflicts(const LOCKTAG *locktag, LOCKMODE lockmode, int *countp)
* the lock, then we needn't examine the individual relation IDs
* at all; none of them can be relevant.
*
* See FastPathTransferLocks() for discussion of why we do this
* test after acquiring the lock.
* See FastPathTransferRelationLocks() for discussion of why we do
* this test after acquiring the lock.
*/
if (proc->databaseId != locktag->locktag_field1)
{