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
-
Provide plpgsql tests for cases involving record field changes.
- c606f10ff832 11.0 landed
- 9f77ad2672f1 12.0 landed
-
Avoid crash in eval_const_expressions if a Param's type changes.
- 9207a64e1496 11.0 landed
- 662d12aea1d6 12.0 landed
-
Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.
- 6719b238e8f0 11.0 cited