Refactor the resource management in INITPLAN function
We introduce function which runs on INITPLAN in commit a21ff2 INITPLAN function is designed to support "CTAS select * from udf();" Since udf() is run on EntryDB, but EntryDB is always read gang which cannot do dispatch work, the query would fail if function contains DDL statement etc. The idea of INITPLAN function is to run the function on INITPLAN, which is QD in fact and store the result into a tuplestore. Later the FunctionScan on EntryDB just read tuple from tuplestore instead of running the real function. But the life cycle management is a little tricky. In the original commit, we hack to close the tuplestore in INITPLAN without deleting the file, and let EntryDB reader to delete the file after finishing the tuple fetch. This will introduce file leak if the transaction abort before the entryDB runs. This commit add a postprocess_initplans in ExecutorEnd() of the main plan to clean the tuplestore createed in preprocess_initplans in ExecutorStart() of the main plan. Note that postprocess_initplans must be place after the dispatch work are finished i.e. mppExecutorFinishup(). Upstream don't need this function since it always use scalar PARAM to communicate between INITPLAN and main plan.
Showing
想要评论请 注册 或 登录