mirror of https://github.com/citusdata/citus.git
56ca256374
After the connection timeout, we fail the session/pool. However, the underlying connection can still be trying to connect. That is dangerous because the new placement executions have already been in place. The executor cannot handle the situation where multiple of EXECUTION_ORDER_ANY task executions succeeds. Adding a regression test doesn't seem easily doable. To reproduce the issue - Add 2 worker nodes - create a reference table - set citus.node_connection_timeout to 1ms (requires code change) - Continiously execute `SELECT count(*) FROM ref_table` - Sometime later, you hit an out-of-array access in `ScheduleNextPlacementExecution()` hence crashing. - The reason for that is sometimes the first connection successfully established while the executor is already trying to execute the query on the second node. |
||
|---|---|---|
| .. | ||
| adaptive_executor.c | ||
| citus_custom_scan.c | ||
| directed_acyclic_graph_execution.c | ||
| distributed_execution_locks.c | ||
| distributed_intermediate_results.c | ||
| insert_select_executor.c | ||
| intermediate_results.c | ||
| local_executor.c | ||
| multi_client_executor.c | ||
| multi_executor.c | ||
| multi_server_executor.c | ||
| partitioned_intermediate_results.c | ||
| placement_access.c | ||
| query_stats.c | ||
| repartition_join_execution.c | ||
| subplan_execution.c | ||
| tuple_destination.c | ||