Re: BUG #15446: Crash on ALTER TABLE

On Sat, 5 Jan 2019 at 00:38, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dmitry Molotkov <aldarund(at)gmail(dot)com> writes:
> > сб, 5 янв. 2019 г. в 01:25, Andres Freund <andres(at)anarazel(dot)de>:
> >> Having to download and run code from dropbox is neither trust-inspiring
> >> (I'd have review all the included code before running it), nor low friction...
>
> > Code is pretty much default empty django project with just with added
> > package that cause error.
>
> It's the "django" part of that that is outside my comfort zone, and I'd
> guess Andres' as well. I don't run django, and I'm not interested in
> learning about it just to reproduce a bug report. As Andres said,
> this would get looked at a lot quicker if the requirements to reproduce
> it were low --- like, say, a small shell or perl or python script.

Boiling down the queries from the links provided, I can reproduce this
with the following simple 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);

which crashes with the following:

#0 0x00007fca1c77515e in __memcpy_sse2_unaligned () from /lib64/libc.so.6
#1 0x0000000000921a6c in datumCopy (value=35278072, typByVal=false, typLen=-1)
at datum.c:159
#2 0x0000000000a2a56d in RelationBuildTupleDesc (relation=0x7fca1343bdc8)
at relcache.c:620
#3 0x0000000000a2b7a0 in RelationBuildDesc (targetRelId=16395, insertIt=false)
at relcache.c:1157
#4 0x0000000000a2df1c in RelationClearRelation (relation=0x7fca13439c88,
rebuild=true) at relcache.c:2446
#5 0x0000000000a2e460 in RelationFlushRelation (relation=0x7fca13439c88)
at relcache.c:2584
#6 0x0000000000a2e572 in RelationCacheInvalidateEntry (relationId=16395)
at relcache.c:2636
#7 0x0000000000a20fac in LocalExecuteInvalidationMessage (msg=0x2161710)
at inval.c:587
#8 0x0000000000a20d0c in ProcessInvalidationMessages (hdr=0x21612a0,
func=0xa20ea9 <LocalExecuteInvalidationMessage>) at inval.c:458
#9 0x0000000000a217dd in CommandEndInvalidationMessages () at inval.c:1093
#10 0x00000000005585c0 in AtCCI_LocalCache () at xact.c:1373
#11 0x0000000000557fd9 in CommandCounterIncrement () at xact.c:955
#12 0x000000000069f819 in ATExecAlterColumnType (tab=0x21a2370,
rel=0x7fca13439c88, cmd=0x21a34d0, lockmode=8) at tablecmds.c:9642
#13 0x0000000000693af6 in ATExecCmd (wqueue=0x7ffcb60097a8, tab=0x21a2370,
rel=0x7fca13439c88, cmd=0x21a34d0, lockmode=8) at tablecmds.c:4181
#14 0x00000000006933b1 in ATRewriteCatalogs (wqueue=0x7ffcb60097a8, lockmode=8)
at tablecmds.c:4025
#15 0x0000000000692b9e in ATController (parsetree=0x21a00c8,
rel=0x7fca13439c88, cmds=0x21a3528, recurse=true, lockmode=8)
at tablecmds.c:3691
#16 0x00000000006928db in AlterTable (relid=16395, lockmode=8, stmt=0x21a00c8)
at tablecmds.c:3365

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.

Regards,
Dean