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

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: a(dot)korotkov(at)postgrespro(dot)ru
Cc: milyutinma(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [BUG] Cache invalidation for queries that contains const of temporary composite type
Date: 2017-10-03 01:30:35
Message-ID: 20171003.103035.166738517.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Sorry, I saw this once but somehow my attension was blown away on
the way.

At Tue, 3 Oct 2017 02:41:34 +0300, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> wrote in <CAPpHfdtCuh5UVezbjA2W+a-tPqXQ6xjAjeH6yyZ1DzxHOSwfsQ(at)mail(dot)gmail(dot)com>
> On Tue, Oct 3, 2017 at 12:20 AM, Maksim Milyutin <milyutinma(at)gmail(dot)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...

Without the patch dropping a table used in a prepared query
results in the similar error. So I suppose it's the desired
behavior in the case.

execute test;
| ERROR: relation "t3" does not exist

The first thought that patch gave me is that the problem is not
limited to constants. Actually the following sequence also
reproduces similar failure even with this patch.

create table t2 (x int , y int);
create type pair as (x int, y int);
prepare test as select row(x, y)::pair from t2;
drop type pair;
execute test;
| ERROR: cache lookup failed for type 16410

In this case the causal expression is in the following form.

TargetEntry (
expr = (
RowExpr:
typeid = 16410,
row_format = COERCE_EXPLICIT_CAST,
args = List (Var(t2.x), Var(t2.y))
)
)

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-10-03 01:31:29 Re: [JDBC] Channel binding support for SCRAM-SHA-256
Previous Message Haribabu Kommi 2017-10-03 01:27:05 Re: Commitfest 201709 is now closed