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
signature.asc
Description: This is a digitally signed message part