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
