mirror of https://github.com/citusdata/citus.git
Fix typo s/exlusive/exclusive/
parent
1af8ca8f7c
commit
76176caea7
|
@ -2660,7 +2660,7 @@ upgrade_columnar_storage(PG_FUNCTION_ARGS)
|
||||||
* ACCESS EXCLUSIVE LOCK is not required by the low-level routines, so we
|
* ACCESS EXCLUSIVE LOCK is not required by the low-level routines, so we
|
||||||
* can take only an ACCESS SHARE LOCK. But all access to non-current
|
* can take only an ACCESS SHARE LOCK. But all access to non-current
|
||||||
* columnar tables will fail anyway, so it's better to take ACCESS
|
* columnar tables will fail anyway, so it's better to take ACCESS
|
||||||
* EXLUSIVE LOCK now.
|
* EXCLUSIVE LOCK now.
|
||||||
*/
|
*/
|
||||||
Relation rel = table_open(relid, AccessExclusiveLock);
|
Relation rel = table_open(relid, AccessExclusiveLock);
|
||||||
if (!IsColumnarTableAmTable(relid))
|
if (!IsColumnarTableAmTable(relid))
|
||||||
|
@ -2696,7 +2696,7 @@ downgrade_columnar_storage(PG_FUNCTION_ARGS)
|
||||||
* ACCESS EXCLUSIVE LOCK is not required by the low-level routines, so we
|
* ACCESS EXCLUSIVE LOCK is not required by the low-level routines, so we
|
||||||
* can take only an ACCESS SHARE LOCK. But all access to non-current
|
* can take only an ACCESS SHARE LOCK. But all access to non-current
|
||||||
* columnar tables will fail anyway, so it's better to take ACCESS
|
* columnar tables will fail anyway, so it's better to take ACCESS
|
||||||
* EXLUSIVE LOCK now.
|
* EXCLUSIVE LOCK now.
|
||||||
*/
|
*/
|
||||||
Relation rel = table_open(relid, AccessExclusiveLock);
|
Relation rel = table_open(relid, AccessExclusiveLock);
|
||||||
if (!IsColumnarTableAmTable(relid))
|
if (!IsColumnarTableAmTable(relid))
|
||||||
|
|
|
@ -117,7 +117,7 @@ AcquireExecutorShardLocksForRelationRowLockList(List *relationRowLockList)
|
||||||
* We have selected these lock types according to conflict table given in the
|
* We have selected these lock types according to conflict table given in the
|
||||||
* Postgres documentation. It is given that FOR UPDATE and FOR NO KEY UPDATE
|
* Postgres documentation. It is given that FOR UPDATE and FOR NO KEY UPDATE
|
||||||
* must be conflict with each other modify command. By getting ExlcusiveLock
|
* must be conflict with each other modify command. By getting ExlcusiveLock
|
||||||
* we guarantee that. Note that, getting ExlusiveLock does not mimic the
|
* we guarantee that. Note that, getting ExclusiveLock does not mimic the
|
||||||
* behaviour of Postgres exactly. Getting row lock with FOR NO KEY UPDATE and
|
* behaviour of Postgres exactly. Getting row lock with FOR NO KEY UPDATE and
|
||||||
* FOR KEY SHARE do not conflict in Postgres, yet they block each other in
|
* FOR KEY SHARE do not conflict in Postgres, yet they block each other in
|
||||||
* our implementation. Since FOR SHARE and FOR KEY SHARE does not conflict
|
* our implementation. Since FOR SHARE and FOR KEY SHARE does not conflict
|
||||||
|
|
|
@ -183,7 +183,7 @@ RecoverWorkerTransactions(WorkerNode *workerNode)
|
||||||
* distributed transactions.
|
* distributed transactions.
|
||||||
*
|
*
|
||||||
* We could avoid this by temporarily blocking new prepared transactions
|
* We could avoid this by temporarily blocking new prepared transactions
|
||||||
* from being created by taking an ExlusiveLock on pg_dist_transaction.
|
* from being created by taking an ExclusiveLock on pg_dist_transaction.
|
||||||
* However, this hurts write performance, so instead we avoid blocking
|
* However, this hurts write performance, so instead we avoid blocking
|
||||||
* by consulting the list of active distributed transactions, and follow
|
* by consulting the list of active distributed transactions, and follow
|
||||||
* a carefully chosen order to avoid race conditions:
|
* a carefully chosen order to avoid race conditions:
|
||||||
|
|
Loading…
Reference in New Issue