mirror of https://github.com/citusdata/citus.git
e7cd1ed0ee
* Not take ShareUpdateExlusiveLock on pg_dist_transaction We were taking ShareUpdateExlusiveLock on pg_dist_transaction during recovery to prevent multiple recoveries happening concurrenly. VACUUM( not FULL) also takes ShareUpdateExclusiveLock, and they can conflict. It seems that VACUUM will skip the table if there is a conflicting lock already taken unless it is doing the vacuum to prevent id wraparound, in which case there can be a deadlock. I guess the deadlock happens if: - VACUUM takes a lock on pg_dist_transaction and is done for id wraparound problem - The transaction in the maintenance tries to take a lock but cannot as that conflicts with the lock acquired by VACUUM - The transaction in the maintenance daemon has a very old xid hence VACUUM cannot proceed. If we take a row exclusive lock in transaction recovery then it wouldn't conflict with VACUUM hence it could proceed so the deadlock would be resolved. To prevent concurrent transaction recoveries happening, an advisory lock is taken with ShareUpdateExlusiveLock as before. * Use CITUS_OPERATIONS tag |
||
|---|---|---|
| .. | ||
| acquire_lock.c | ||
| aggregate_utils.c | ||
| cancel_utils.c | ||
| citus_clauses.c | ||
| citus_copyfuncs.c | ||
| citus_nodefuncs.c | ||
| citus_outfuncs.c | ||
| citus_readfuncs.c | ||
| citus_safe_lib.c | ||
| citus_version.c | ||
| colocation_utils.c | ||
| distribution_column.c | ||
| enable_ssl.c | ||
| errormessage.c | ||
| foreign_key_relationship.c | ||
| function_utils.c | ||
| hash_helpers.c | ||
| listutils.c | ||
| log_utils.c | ||
| maintenanced.c | ||
| multi_partitioning_utils.c | ||
| namespace_utils.c | ||
| pg11_snprintf.c | ||
| query_utils.c | ||
| reference_table_utils.c | ||
| resource_lock.c | ||
| role.c | ||
| shard_utils.c | ||
| shardinterval_utils.c | ||
| statistics_collection.c | ||
| task_execution_utils.c | ||
| tuplestore.c | ||