On Sat, Oct 24, 2015 at 6:31 PM, Noah Misch <noah@leadboat.com> wrote:
> On Sat, Oct 24, 2015 at 07:49:07AM -0400, Robert Haas wrote:
>> On Fri, Oct 23, 2015 at 9:38 PM, Noah Misch <noah@leadboat.com> wrote:
>> > Since that specification permits ParamListInfo consumers to ignore paramMask,
>> > the plpgsql_param_fetch() change from copy-paramlistinfo-fixes.patch is still
>> > formally required.
>>
>> So why am I not just doing that, then? Seems a lot more surgical.
>
> do $$
> declare
> param_unused text := repeat('a', 100 * 1024 * 1024);
> param_used oid := 403;
> begin
> perform count(*) from pg_am where oid = param_used;
> end
> $$;
>
> I expect that if you were to inspect the EstimateParamListSpace() return
> values when executing that, you would find that it serializes the irrelevant
> 100 MiB datum. No possible logic in plpgsql_param_fetch() could stop that
> from happening, because copyParamList() and SerializeParamList() call the
> paramFetch hook only for dynamic parameters. Cursors faced the same problem,
> which is the raison d'être for setup_unshared_param_list().
Well, OK. That's not strictly a correctness issue, but here's an
updated patch along the lines you suggested.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
