Re: 11beta crash/assert caused by parameter type changes

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Vik Fearing <vik.fearing@2ndquadrant.com>, Andrew Gierth <andrew@tao11.riddles.org.uk>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-07-26T19:20:08Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jul 26, 2018 at 2:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I was about to add Andrew's example as a test case (also shown in
>> attached), but realized that there's a problem: just as noted in
>> the similar test for named-composite-type changes a bit above there,
>> the failure fails to fail in CLOBBER_CACHE_ALWAYS builds.

> Sorry if this is a dumb question, but why does that happen?  I thought
> that the idea was that CLOBBER_CACHE_ALWAYS shouldn't change
> semantics.

What we need to fix the problem properly is to forcibly replan a
plancache entry when the type of one of the query's input parameters
changes.  If you turn on CCA, plancache entries are forcibly replanned
at every use.  So, problem goes away (in the most expensive way
possible).

			regards, tom lane


Commits

  1. Provide plpgsql tests for cases involving record field changes.

  2. Avoid crash in eval_const_expressions if a Param's type changes.

  3. Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.