On Sat, Oct 17, 2015 at 6:15 AM, Noah Misch <n...@leadboat.com> wrote: > > On Thu, Oct 15, 2015 at 04:30:01PM +0530, Amit Kapila wrote: > > On Mon, Oct 12, 2015 at 9:16 PM, Robert Haas <robertmh...@gmail.com> wrote: > > > plpgsql_param_fetch() assumes that it can detect whether it's being > > > called from copyParamList() by checking whether params != > > > estate->paramLI. I don't know why this works, but I do know that this > > > test fails to detect the case where it's being called from > > > SerializeParamList(), which causes failures in exec_eval_datum() as > > > predicted. Calls from SerializeParamList() need the same treatment as > > > calls from copyParamList() because it, too, will try to evaluate every > > > parameter in the list. > > > > From what I understood by looking at code in this area, I think the check > > params != estate->paramLI and code under it is required for parameters > > that are setup by setup_unshared_param_list(). Now unshared params > > are only created for Cursors and expressions that are passing a R/W > > object pointer; for cursors we explicitly prohibit the parallel > > plan generation > > and I am not sure if it makes sense to generate parallel plans for > > expressions > > involving R/W object pointer, if we don't generate parallel plan where > > expressions involve such parameters, then SerializeParamList() should not > > be affected by the check mentioned by you. > > The trouble comes from the opposite direction. A setup_unshared_param_list() > list is fine under today's code, but a shared param list needs more help. To > say it another way, parallel queries that use the shared estate->paramLI need, > among other help, the logic now guarded by "params != estate->paramLI". >
Why would a parallel query need such a logic, that logic is needed mainly for cursor with params and we don't want a parallelize such cases? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
