Re: [BUG] Cache invalidation for queries that contains const of temporary composite type

25.09.17 20:50, Maksim Milyutin wrote:

> I have found out the problem when try to sequentially call the
> function that casts constant to composite type of temporary table that
> is deleted ateach transaction termination (i.e. at each function call
> completion).
>
>
> For example, we have the following function 'test':
>
> CREATE OR REPLACE FUNCTION test()
>  RETURNS void
>  LANGUAGE plpgsql
> AS $function$
> begin
>     create temp table tbl (id int) on commit drop;
>     perform json_populate_record(null::tbl, '{ "id": 11 }'::json) as tt;
> end;
> $function$
>
>
> Оn the second and subsequent calls we'll observe the following error:
>
> ERROR:  cache lookup failed for type 16392
>
>
> I investigated the problem and realized that result type of function
> *json_populate_record* (/funcresulttype/ field of /FuncExpr/ struct)
> as well as type of the first null argument (/consttype/ field of
> /Const/ struct) refer to the invalid composite type related with
> temporary table'tbl'. Namely they take a value of oid gotten from the
> first 'tbl' initialization. The plan of query *'perform
> json_populate_record(null::tbl, '{ "id": 11 }'::json) as tt'*is cached
> and is not invalidated at each function call. This is because** the
> statement of this query doesn't have any dependency from the 'tbl'
> relation (/relationOids/ list of /CachedPlanSource/ struct).
>
>
> Attached patch resolves this problem by adding dependency from
> relation upon detection Const expression of composite type of that
> relation

Updated patchset contains more transparent definition of composite type
for constant node and regression test for described above buggy case.

--
Regards,
Maksim Milyutin