Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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:14:53Z
Lists: pgsql-hackers 
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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.