segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function - Mailing list pgsql-hackers

From Geoff Winkless
Subject segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function
Date
Msg-id CAEzk6fdVan-rUr5Le2BfNfKncniMdyk4vyVZYnKX_TBJu34Zdw@mail.gmail.com
Whole thread Raw
Responses Re: segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function  (Michael Paquier <michael.paquier@gmail.com>)
Re: segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi all

While doing some testing of 9.5a one of my colleagues (not on list) found a reproducible server segfault.

We've broken it down to a minimal script to reproduce below.

Reproduced on both machines on which we've installed 9.5 so far (both built from source since we don't have any RHEL7 machines in development):

RHEL5.3 (Linux 2.6.18-128.el5 i386), gcc version 4.6.4
CentOS 6.5 (Linux 2.6.32-431.el6.i686), gcc version 4.4.7-4

Script for psql:

============ cut ===============

CREATE OR REPLACE FUNCTION to_date(integer) RETURNS date LANGUAGE sql IMMUTABLE AS $$

SELECT $1::text::date

$$;


DROP CAST IF EXISTS (integer AS date);

CREATE CAST (integer AS date) WITH FUNCTION to_date(integer) AS IMPLICIT;

 

CREATE OR REPLACE FUNCTION newcrash(INTEGER) returns DATE LANGUAGE plpgsql AS $$ BEGIN

RETURN $1;

END$$;


SELECT newcrash(20150202);

SELECT newcrash(20150203);


============ cut ===============



It doesn't crash the first time, but does consistently crash the second. Given that if I remove IMMUTABLE from the function definition it doesn't fail, it implies that there's a problem with the mechanism used to cache function results - although the fact that the second function call doesn't have to be the same value does suggest it's a problem with the code that searches that result cache, rather than the section that retrieves it. 


I tried cutting out the implicit CAST altogether and doing

RETURN to_date($1);


but this doesn't fail, which implies also that it's something related to the implicit cast.


If I DECLARE a local DATE variable and SELECT INTO that (rather than just using RETURN $1), it crashes at that point too.


Hope someone can get something useful from the above. Any questions, please ask.


Geoff

pgsql-hackers by date:

Previous
From: Brendan Jurd
Date:
Subject: Re: [PATCH] Function to get size of asynchronous notification queue
Next
From: Robert Haas
Date:
Subject: Re: Retrieve the snapshot's LSN