On Thu, Oct 15, 2015 at 7:00 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Mon, Oct 12, 2015 at 9:16 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Sun, Oct 11, 2015 at 7:56 PM, Noah Misch <n...@leadboat.com> wrote: >> > I see no mention in this thread of varatt_indirect, but I anticipated >> > datumSerialize() reacting to it the same way datumCopy() reacts. If >> > datumSerialize() can get away without doing so, why is that? >> >> Good point. I don't think it can. Attached is a patch to fix that. >> This patch also includes some somewhat-related changes to >> plpgsql_param_fetch() upon which I would appreciate any input you can >> provide. >> >> 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. Is by anychance, this is > happening because you are testing by forcing gather node on top of > all kind of plans?
Yeah, but I think the scenario is legitimate. When a query gets run from within PL/pgsql, parallelism is an option, at least as we have the code today. So if a Gather were present, and the query used a parameter, then you could have this issue. For example: SELECT * FROM bigtable WHERE unindexed_column = some_plpgsql_variable; So this can happen, I think, even with parallel sequential scan only, even if Gather node is not otherwise used. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
