mirror of https://github.com/citusdata/citus.git
* Fix problews with concurrent calls of DropMarkedShards
When trying to enable `citus.defer_drop_after_shard_move` by default it
turned out that DropMarkedShards was not safe to call concurrently.
This could especially cause big problems when also moving shards at the
same time. During tests it was possible to trigger a state where a shard
that was moved would not be available on any of the nodes anymore after
the move.
Currently DropMarkedShards is only called in production by the
maintenaince deamon. Since this is only a single process triggering such
a race is currently impossible in production settings. In future changes
we will want to call DropMarkedShards from other places too though.
* Add some isolation tests
Co-authored-by: Jelte Fennema <github-tech@jeltef.nl>
(cherry picked from commit
|
||
---|---|---|
.. | ||
citus_create_restore_point.c | ||
citus_tools.c | ||
create_shards.c | ||
delete_protocol.c | ||
modify_multiple_shards.c | ||
node_protocol.c | ||
partitioning.c | ||
repair_shards.c | ||
shard_cleaner.c | ||
shard_rebalancer.c | ||
split_shards.c | ||
stage_protocol.c | ||
worker_node_manager.c |