babelfish-for-postgresql
/
babelfish_extensions
/
15208244170
/
1
74%
BABEL_5_X_DEV: 77%
BABEL_5_X_DEV: 77%
|
Ran
|
Files
115
|
Run time
4s
|
Badge
Embed ▾
README BADGES
|
coverage: 74.053% (+0.009%) from 74.044%
push
github
web-flowAllow parallelism for pltsql return expression after community commit 556f7b7 (#3725) (#3773) With the commit 556f7b7, we unintentionally blocked parallelism to evaluate plpgsql return expression because maxtuples = 2 is being passed to exec_run_select(...) from exec_eval_expr(...) to evaluate the return expression of the plpgsql function. Idea to fix this issue to pass maxtuples = 0. It is safe to do it because number of processed rows is anyway being checked later in exec_eval_expr(...). But with this, there is not real caller remained which calls exec_run_select(...) with maxtuple != 0 so updated definition of exec_run_select(...) to remove maxtuples argument. This commit also fixes parallel context leak in case of statement terminating error originating from PLTSQL function body. This is important because subsequent resetting search_path or table variable cleanup operations may end up error. Task: BABEL-5599 (cherry picked from commit b3f148486) Signed-off-by: Dipesh Dhameliya <dipeshdhameliya125@gmail.com>
43793 of 59137 relevant lines covered (74.05%)
212030.42 hits per line
