Re: 9.5.4: Segfault (signal 11) while running ALTER TABLE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 9.5.4: Segfault (signal 11) while running ALTER TABLE
Date
Msg-id 22548.1472559517@sss.pgh.pa.us
Whole thread Raw
In response to 9.5.4: Segfault (signal 11) while running ALTER TABLE  (Devrim Gündüz <devrim@gunduz.org>)
Responses Re: 9.5.4: Segfault (signal 11) while running ALTER TABLE  (Devrim Gündüz <devrim@gunduz.org>)
List pgsql-hackers
Devrim Gündüz <devrim@gunduz.org> writes:
> 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.

The above isn't ever likely to work for any large value of "work",
because the function would be confused about what the table rowtype
is.  I thought we had adequate defenses in there to throw an error
if you try to access a table that's in the middle of being altered,
but apparently this case isn't covered.

Why didn't they just doALTER TABLE foo1 ALTER COLUMN id TYPE INTEGER USING newid;
?  The intermediate function sure seems like the hard way.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: old_snapshot_threshold documentation
Next
From: Peter Eisentraut
Date:
Subject: sequences and pg_upgrade