根据代码分析，问题出在check_conflicting_endpoints函数（control_plane/src/endpoint.rs:277），它检查是否存在同一tenant_id + timeline_id上处于非Stopped状态的 endpoint。计算节点异常退出后可能留下了残留的postmaster.pid文件，导致status()返回Crashed而非Stopped，从而触发冲突校验。
有两种解决方案：
方案一：加 --allow-multiple 参数启动（最简单）
代码注释明确说明这个参数用途：
“Allow multiple primary endpoints running on the same branch. Shouldn't be used normally, but useful for tests.”
如果这是本地开发环境，可以直接加参数绕过检查：
cargo neon endpoint start <endpoint_id> --allow-multiple方案二：删除残留 pidfile 文件，让状态变为 Stopped
计算节点异常退出后postmaster.pid可能残留，导致status()判断为Crashed（因为has_pidfile=true但can_connect=false）。删除这个文件可以让状态重置为Stopped，然后正常启动：
# 找到端点目录下的 pgdata/postmaster.pid rm <neon_data_dir>/endpoints/<endpoint_id>/pgdata/postmaster.pid然后根据实际的 neon 数据目录路径定位到这个文件。删除后再次执行普通的cargo neon endpoint start即可，因为此时check_conflicting_endpoints会看到EndpointStatus::Stopped而跳过检查。
推荐先尝试方案二（更干净），如果不行再用方案一绕过。
