Re: BUG #15446: Crash on ALTER TABLE

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dmitry Molotkov <aldarund(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15446: Crash on ALTER TABLE
Date: 2019-01-06 22:40:16
Message-ID: f66296a1-2b66-e392-0ba0-64175d0846ec@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers


On 1/5/19 12:09 PM, Andres Freund wrote:
> Hi,
>
> On 2019-01-05 12:11:45 +0000, Dean Rasheed wrote:
>> It looks like the problem was introduced in PG11 by 16828d5c02 (Fast
>> ALTER TABLE ADD COLUMN with a non-NULL default). The first ALTER TABLE
>> adds a new column with a non-null default, setting atthasmissing and
>> attmissingval. Then the second ALTER TABLE changes the type of the new
>> column, but it fails to update attmissingval to match, and thus it
>> falls over when trying to re-open the relation because the value in
>> attmissingval is no longer compatible with the attribute type.
> Paging Dr Dunstan.

Investigating with this test case:

DROP TABLE IF EXISTS foo;
CREATE TABLE foo (a int);
ALTER TABLE foo ADD COLUMN b double precision DEFAULT 0.2;
ALTER TABLE foo ALTER COLUMN b TYPE varchar(5) USING b::varchar(5);

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Rowley 2019-01-07 01:57:25 Re: BUG #15577: Query returns different results when executed multiple times
Previous Message PG Bug reporting form 2019-01-06 16:26:04 BUG #15577: Query returns different results when executed multiple times

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2019-01-06 22:50:36 Re: [PATCH] check for ctags utility in make_ctags
Previous Message Tom Lane 2019-01-06 22:08:59 Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)