fix scope.ParallelRun bug which cause hung when error happens.

[m-schen]

User description

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

issue #16439

What this PR does / why we need it:

修复了一个在pipeline执行前发生错误会导致其他已启动的pipeline（如各种带有收数据功能的pipeline）卡死的问题。

---

PR Type

Bug fix

---

Description

• Refactored the ParallelRun function in pkg/sql/compile/scope.go to handle different pipeline types (JOIN, LOAD, SCAN) by introducing helper functions buildJoinParallelRun, buildLoadParallelRun, and buildScanParallelRun.
• Removed the remote parameter from the ParallelRun function and updated its calls accordingly.
• Reorganized import statements in pkg/sql/compile/scope.go.

---

Changes walkthrough 📝

Relevant files

Bug fix

scope.go Refactor ParallelRun and add helper functions for different pipeline types. pkg/sql/compile/scope.go Refactored ParallelRun to handle different pipeline types (JOIN, LOAD, SCAN). Added helper functions buildJoinParallelRun, buildLoadParallelRun, and buildScanParallelRun. Removed the remote parameter from ParallelRun. Updated import statements and reorganized them. +364/-318 scopeRemoteRun.go Remove `remote` parameter from `ParallelRun` call.              pkg/sql/compile/scopeRemoteRun.go Removed the remote parameter from the ParallelRun call. +1/-1

---

💡 PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

[codiumai-pr-agent-pro]

PR Review 🔍

⏱️ Estimated effort to review [1-5]	4, because the PR involves complex refactoring of the ParallelRun function with multiple helper functions and conditions. It requires a deep understanding of the existing codebase and the specific functionalities being refactored.
🧪 Relevant tests	No
⚡ Possible issues	Possible Bug: The refactoring introduces multiple helper functions like buildJoinParallelRun, buildLoadParallelRun, and buildScanParallelRun. There is a risk of introducing bugs if these functions do not handle all edge cases or maintain the original logic accurately.
	Performance Concern: The changes in how parallelism is handled (e.g., determining the number of CPUs to use) could impact performance. It's crucial to ensure that performance does not degrade, especially in different deployment environments that may have varying hardware configurations.
🔒 Security concerns	No

[codiumai-pr-agent-pro]

PR Code Suggestions ✨

Category	Suggestion	Score
Best practice	Add error logging for the ParallelRun function to aid in debugging Consider adding a log statement or error handling mechanism to capture and log the error returned by s.ParallelRun(c). This will help in debugging and understanding the cause of the error. pkg/sql/compile/scopeRemoteRun.go [215-216] err = s.ParallelRun(c) -if err == nil { +if err != nil { + log.Errorf("ParallelRun failed: %v", err) + return err +} Suggestion importance[1-10]: 8 Why: The suggestion correctly identifies a missing error handling mechanism for the s.ParallelRun(c) method, which is crucial for debugging and maintaining robustness in error scenarios.	8
Possible issue	Add a nil check for the context before setting it recursively Ensure that the context c.ctx is not nil before calling SetContextRecursively to prevent potential runtime panics. pkg/sql/compile/scopeRemoteRun.go [213] -s.SetContextRecursively(c.ctx) +if c.ctx != nil { + s.SetContextRecursively(c.ctx) +} else { + log.Warn("Context is nil, skipping SetContextRecursively") +} Suggestion importance[1-10]: 7 Why: Adding a nil check before using the context can prevent runtime panics, which is a good practice for ensuring the stability of the application. However, the PR does not indicate issues with c.ctx being nil, so the suggestion is preventive rather than corrective.	7

[m-schen]

修改后的 parallel run 执行流程：

1. 根据是否为join, 是否为scan等，生成可并行执行的pipeline。
2. 执行pipeline.

其中第一部分如果有任意报错，将会执行pipeline.cleanup确保其接受者等可以正常退出。