On Sat, Oct 17, 2015 at 11:45 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > > Agreed and on looking at code, I think in below code, if we pass > parallelOK as true for the cases where Portal is non-null, such a > problem could happen. > > > static int > > exec_run_select(PLpgSQL_execstate *estate, > > PLpgSQL_expr *expr, long maxtuples, Portal *portalP, > > bool parallelOK) > > { > > ParamListInfo paramLI; > > int rc; > > > /* > > * On the first call for this expression generate the plan > > */ > > if (expr->plan == NULL) > > exec_prepare_plan(estate, expr, parallelOK ? > > CURSOR_OPT_PARALLEL_OK : 0); > > > /* > > * If a portal was requested, put the query into the portal > > */ > > if (portalP != NULL) > > { > > /* > > * Set up short-lived ParamListInfo > > */ > > paramLI = setup_unshared_param_list(estate, expr); > > > *portalP = SPI_cursor_open_with_paramlist(NULL, expr->plan, > > paramLI, > > estate->readonly_func); > > > > > and one such case is > > exec_stmt_return_query() > { > .. > > if (stmt->query != NULL) > > { > > /* static query */ > > exec_run_select(estate, stmt->query, 0, &portal, true); > > .. > } > > > In this function we are using controlled fetch mechanism (count as 50) to > fetch the tuples which we initially thought of not supporting for parallelism, > as such a mechanism is not built for parallel workers and that is the > reason we want to prohibit cases where ever cursor is getting created. >
Here, I wanted to say that is one of the reasons for prohibiting cursors
for parallelism, certainly there are others like Backward scan.
