Re: BUG #15446: Crash on ALTER TABLE - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: BUG #15446: Crash on ALTER TABLE
Date
Msg-id 9e4caaa2-e2af-fd7f-e864-ae67e9560579@2ndQuadrant.com
Whole thread Raw
Responses Re: BUG #15446: Crash on ALTER TABLE  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers
On 1/8/19 4:48 PM, Dean Rasheed wrote:
> On Tue, 8 Jan 2019 at 19:34, Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com> wrote:
>> Here's a patch that I think cures the problem.
>>
> Hmm, that doesn't quite work because the table might not actually be
> rewritten as a result of the type change. For example:
>
> DROP TABLE IF EXISTS foo;
> CREATE TABLE foo (a int);
> INSERT INTO foo VALUES (1);
> ALTER TABLE foo ADD COLUMN b varchar(10) DEFAULT 'xxx';
> ALTER TABLE foo ALTER COLUMN b SET DEFAULT 'yyy';
> INSERT INTO foo VALUES (2);
> SELECT * FROM foo;
>  a |  b
> ---+-----
>  1 | xxx
>  2 | yyy
> (2 rows)
>
> ALTER TABLE foo ALTER COLUMN b TYPE varchar(20) USING b::varchar(20);
> SELECT * FROM foo;
>  a |  b
> ---+-----
>  1 |
>  2 | yyy
> (2 rows)
>


Ouch, OK, looks like we need something more complex.


cheers


andrew


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



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0
Next
From: Peter Geoghegan
Date:
Subject: Re: Making all nbtree entries unique by having heap TIDs participatein comparisons