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

On 26.09.2017 23:25, Maksim Milyutin wrote:

> 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.

Is there any interest on the problem in this thread?

--
Regards,
Maksim Milyutin