Re: [HACKERS][BUG] Cache invalidation for queries that contains constof temporary composite type - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: [HACKERS][BUG] Cache invalidation for queries that contains constof temporary composite type
Date
Msg-id CAPpHfdtCuh5UVezbjA2W+a-tPqXQ6xjAjeH6yyZ1DzxHOSwfsQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS][BUG] Cache invalidation for queries that contains constof temporary composite type  (Maksim Milyutin <milyutinma@gmail.com>)
Responses Re: [HACKERS][BUG] Cache invalidation for queries that containsconst of temporary composite type
List pgsql-hackers
On Tue, Oct 3, 2017 at 12:20 AM, Maksim Milyutin <milyutinma@gmail.com> wrote:

I have tested the following case:

create type pair as (x int, y int);
prepare test as select json_populate_record(null::pair, '{"x": 1, "y": 2}'::json);
drop type pair cascade;

execute test;

-- The following output is obtained before patch
ERROR:  cache lookup failed for type 16419

-- After applying patch
ERROR:  type "pair" does not exist

But after recreating 'pair' type I'll get the following message:
ERROR:  cached plan must not change result type

I don't know whether it's right behavior. Anyhow your point is a good motivation to experiment and investigate different scenarios of work with cached plan that depends on non-stable type. Thanks for that.


I think ideally, cached plan should be automatically invalidated and stored procedure should work without error.
Not really sure if it's feasible...

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
 

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra