Files
doris/regression-test
Luwei d209c16d81 [fix](schema-change) fix the bug of alter column nullable when double writing (#41737) (#42352)
pick master #41737 

## problem 

CREATE TABLE t (
    `k1` VARCHAR(30) NOT NULL,
    `v1` INT NOT NULL
)

alter table t modify column `v1` INT NULL

insert into value ('1', 2), ('1', 3);

core dump

## reason

Schema change leads to double writing, during double writing, the two
schemas and slots are as follows
 
```
old tablet schema 
k1 varchar not null
v1 int not null
```
 
```
new tablet scheam
k1 varchar not null
v1 int null
```

```
slot
k1 varchar not null
v1 int not null
v1 int null
```

During the double writing process, when selecting slots through the
schema, only the column names and types were compared, without comparing
the nullable attributes, which led to the selection of the wrong slot.
Since the slot determines the nullable attribute of the block, the
nullable attribute of the columns in the block is different from that of
the columns in the schema, resulting in a core dump.

## Proposed changes

Issue Number: close #xxx

<!--Describe your changes.-->
2024-10-24 16:49:46 +08:00
..

Guide for test cases

General Case

  1. Write "def" before variable names; otherwise, they will be global variables and may be affected by other cases running in parallel.

    Problematic code:

    ret = ***
    

    Correct code:

    def ret = ***
    
  2. Avoid setting global session variables or modifying cluster configurations in cases, as it may affect other cases.

    Problematic code:

    sql """set global enable_pipeline_x_engine=true;"""
    

    Correct code:

    sql """set enable_pipeline_x_engine=true;"""
    
  3. If it is necessary to set global variables or modify cluster configurations, specify the case to run in a nonConcurrent manner.

    Example

  4. For cases involving time-related operations, it is best to use fixed time values instead of dynamic values like the now() function to prevent cases from failing after some time.

    Problematic code:

    sql """select count(*) from table where created < now();"""
    

    Correct code:

    sql """select count(*) from table where created < '2023-11-13';"""
    
  5. After streamloading in a case, add a sync to ensure stability when executing in a multi-FE environment.

    Problematic code:

    streamLoad { ... }
    sql """select count(*) from table """
    

    Correct code:

    streamLoad { ... }
    sql """sync"""
    sql """select count(*) from table """
    
  6. For UDF cases, make sure to copy the corresponding JAR file to all BE machines.

    Example

  7. Do not create the same table in different cases under the same directory to avoid conflicts.

Compatibility case

Refers to the resources or rules created on the initial cluster during FE testing or upgrade testing, which can still be used normally after the cluster restart or upgrade, such as permissions, UDF, etc.

These cases need to be split into two files, load.groovy and xxxx.groovy, placed in a folder, and tagged with the restart_fe group label, example.