9.5.4: Segfault (signal 11) while running ALTER TABLE

Hi,

I received an email offlist about a crash that a non-customer experienced
recently. I asked them to send a few details about the crash, so here it is.
Please note that I don't have access to their systems, but they will be fast
enough to provide data if needed. (They asked me to mask some of the table/func
names)

They have a domain called primaryuuid:

CREATE DOMAIN primaryuuid AS uuid NOT NULL DEFAULT uuid_generate_v4();

and a table called foo1, which used to have this domain as a data type:

CREATE TABLE foo1 (
    id public.primaryuuid NOT NULL,
 <some more columns>
    tempuuid uuid
);

They wanted to change id column from uuid to int, so created this func first:

CREATE FUNCTION foofunc_id_uuidtoint(chartoconvert uuid) RETURNS integer
    LANGUAGE sql IMMUTABLE STRICT
    AS $_$
SELECT newid FROM foo1 WHERE tempuuid = $1 LIMIT 1;
$_$;

and ran this:

ALTER TABLE foo1 ALTER COLUMN id TYPE INTEGER USING
foofunc_id_uuidtoint(tempuuid);

This command crashed postmaster. They connected to related process once again
with gdb, and got this:

===========
Program received signal SIGSEGV, Segmentation fault.
slot_deform_tuple (slot=0x1b80440, natts=13) at heaptuple.c:1157
1157 values[attnum] = fetchatt(thisatt, tp + off);
Continuing.
===========

Below are some lines in postgresql.log:

==============================================================
ERROR:  canceling autovacuum task
CONTEXT:  automatic vacuum of table "foo1"
process 10884 acquired AccessExclusiveLock on relation 16961 of database 16401
after 1000.411 ms
STATEMENT:  ALTER TABLE foo1 ALTER COLUMN id TYPE INTEGER USING
foofunc_id_uuidtoint(tempuuid);
LOG:  server process (PID 10884) was terminated by signal 11: Segmentation
fault
==============================================================

Please note that this crash is not specific to this table. Various attempts to change this data type on various tables also crashed postmaster.

This happened a few times, and after disabling autovacuum and lowering
maintenance_work_mem from 4GB to 2GB, they could complete all ALTER TABLE
commands.

This is PostgreSQL 9.5.4 on CentOS 6.8, fully up2date, and they are using the
community RPMs. 

Any ideas what is causing this crash?

Please let me know if you need more data.

Regards,
--
Devrim GÜNDÜZ
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR