<!-- #请认真填写以下信息，否则可能由于无法定位，导致issue无法解决而被取消 -->

【标题描述】:并发执行和修改A风格存储过程，存在宕机的可能性

【测试类型：SQL功能】【测试版本：7.0.0-RC1】 并发执行和修改A风格存储过程，存在宕机的可能性

【操作系统和硬件信息】(查询命令: cat /etc/system-release, uname -a): x86 + centos7

【测试环境】(单机/1主x备x级联备): 单机

【被测功能】: SQL语法

【测试类型】: 功能测试

【数据库版本】(查询命令: gaussdb -V):


【预置条件】: 无

【操作步骤】(请填写详细的操作步骤):

1. 初始化实例，并创建存储过程，然后重启进程

```

create or replace procedure proc1_1258266(col1 date,col2 inout timestamp,col3 out date)

as

begin

col2:=col2+10;

col3:=col1+15;

end;

/

call proc1_1258266('2023-1-1','2024-1-1 11:15:12',null);

```

2. 登录两个新会话，两个会话预先输入以下sql命令，并且不要执行

会话1

```

call proc1_1258266('2023-1-1','2024-1-1 11:15:12',null);

```

<!-- #请认真填写以下信息，否则可能由于无法定位，导致issue无法解决而被取消 -->

【标题描述】:并发执行和修改A风格存储过程，存在宕机的可能性

【测试类型：SQL功能】【测试版本：7.0.0-RC1】 并发执行和修改A风格存储过程，存在宕机的可能性

【操作系统和硬件信息】(查询命令: cat /etc/system-release, uname -a): x86 + centos7

【测试环境】(单机/1主x备x级联备): 单机

【被测功能】: SQL语法

【测试类型】: 功能测试

【数据库版本】(查询命令: gaussdb -V):


【预置条件】: 无

【操作步骤】(请填写详细的操作步骤):

1. 初始化实例，并创建存储过程，然后重启进程

```

create or replace procedure proc1_1258266(col1 date,col2 inout timestamp,col3 out date)

as

begin

col2:=col2+10;

col3:=col1+15;

end;

/

call proc1_1258266('2023-1-1','2024-1-1 11:15:12',null);

```

2. 登录两个新会话，两个会话预先输入以下sql命令，并且不要执行

会话1

```

call proc1_1258266('2023-1-1','2024-1-1 11:15:12',null);

```

会话2

```

create or replace procedure proc1_1258266(col1 varchar,col2 inout varchar,col3 out text)

as

begin

col2:=length(col2)+10;

col3:=length(col1)+15;

end;

/

```

3.使用gdb调试，如下图操作


4.打断点，线程3是会话1所在的线程


第3个断点依据实际代码行数打上，参考代码，目的是为了观察proc_source这一字符串变量


5.执行会话1的语句，此时会阻塞在断点1，如下图操作，先切换到线程3，然后执行两次finish，让sql命令执行一小段


6.执行会话2，修改存储过程，会话2的命令会顺序完成

7.在gdb执行continue命令，当执行到断点3时，可以打印proc_source，此时proc_source是修改后的存储过程的prosrc,继续执行下去会发生宕机


【预期输出】:

不会宕机，并且报错

【实际输出】:

宕机

【原因分析】:

1. 这个问题的根因

语义分析阶段，会根据实际的函数/存储过程声明，把参数表达式转换为目标参数类型的表达式，这一处理见ParseFuncOrColumn->make_fn_arguments，即此时会确定入参表达式的类型。发生宕机的原因是，语义分析阶段已经把参数确定为日期类型的常量。但语义解析后，其他会话的事务修改了函数定义，并且把参数类型修改了，同时由于本会话后续消费了无效消息，函数编译时(见plpgsql_compile函数)读取了新版本的函数定义，导致把日期类型的表达式作为textlen函数的入参，textlen函数把日期类型的表达式作为字符类型表达式处理，发生宕机。

1）core文件中toastpointer指针值比较诡异，且无法转成varattrib_1b类型后无法打印


2）正常情况下toastpointer，可以打印header


3）把core文件里的变量按照Const来打印(ExecMakeTableFunctionResult函数)，其类型是9040，即oradate，可以推断，有可能是解析参数是还是按照旧版本的元数据来解析，但是执行时使用了新版本的源数据库，导致把日期类型的表达式作为textlen函数的入参，发生宕机


2. 问题推断过程

3. 还有哪些原因可能造成类似现象

4. 该问题是否有临时规避措施

5. 问题解决方案

考虑以下一个方案：

FunctionCallInfo结构能否增加一个版本号，在plpgsql_exec_function函数内，与PLpgSQL_function.fn_xmin比较，如果不一致就报错

该方案只是初步设想，还需要社区专家给出更多意见

6. 预计修复问题时间

【日志信息】(请附上日志文件、截图、coredump信息):

【测试代码】:

见操作步骤

<!-- #请认真填写以下信息，否则可能由于无法定位，导致issue无法解决而被取消 -->

【标题描述】:并发执行和修改A风格存储过程，存在宕机的可能性

【测试类型：SQL功能】【测试版本：7.0.0-RC1】 并发执行和修改A风格存储过程，存在宕机的可能性

【操作系统和硬件信息】(查询命令: cat /etc/system-release, uname -a): x86 + centos7

【测试环境】(单机/1主x备x级联备): 单机

【被测功能】: SQL语法

【测试类型】: 功能测试

【数据库版本】(查询命令: gaussdb -V):


【预置条件】: 无

【操作步骤】(请填写详细的操作步骤):

1. 初始化实例，并创建存储过程，然后重启进程

```

create or replace procedure proc1_1258266(col1 date,col2 inout timestamp,col3 out date)

as

begin

col2:=col2+10;

col3:=col1+15;

end;

/

call proc1_1258266('2023-1-1','2024-1-1 11:15:12',null);

```

2. 登录两个新会话，两个会话预先输入以下sql命令，并且不要执行

会话1

```

call proc1_1258266('2023-1-1','2024-1-1 11:15:12',null);

```

会话2

```

create or replace procedure proc1_1258266(col1 varchar,col2 inout varchar,col3 out text)

as

begin

col2:=length(col2)+10;

col3:=length(col1)+15;

end;

/

```

3.使用gdb调试，如下图操作


4.打断点，线程3是会话1所在的线程


第3个断点依据实际代码行数打上，参考代码，目的是为了观察proc_source这一字符串变量


5.执行会话1的语句，此时会阻塞在断点1，如下图操作，先切换到线程3，然后执行两次finish，让sql命令执行一小段


6.执行会话2，修改存储过程，会话2的命令会顺序完成

7.在gdb执行continue命令，当执行到断点3时，可以打印proc_source，此时proc_source是修改后的存储过程的prosrc,继续执行下去会发生宕机


【预期输出】:

不会宕机，并且报错

【实际输出】:

宕机

【原因分析】:

1. 这个问题的根因

语义分析阶段，会根据实际的函数/存储过程声明，把参数表达式转换为目标参数类型的表达式，这一处理见ParseFuncOrColumn->make_fn_arguments，即此时会确定入参表达式的类型。发生宕机的原因是，语义分析阶段已经把参数确定为日期类型的常量。但语义解析后，其他会话的事务修改了函数定义，并且把参数类型修改了，同时由于本会话后续消费了无效消息，函数编译时(见plpgsql_compile函数)读取了新版本的函数定义，导致把日期类型的表达式作为textlen函数的入参，textlen函数把日期类型的表达式作为字符类型表达式处理，发生宕机。

1）core文件中toastpointer指针值比较诡异，且无法转成varattrib_1b类型后无法打印

2）正常情况下toastpointer，可以打印header


2. 问题推断过程

3. 还有哪些原因可能造成类似现象

4. 该问题是否有临时规避措施

5. 问题解决方案

考虑以下一个方案：

FunctionCallInfo结构能否增加一个版本号，在plpgsql_exec_function函数内，与PLpgSQL_function.fn_xmin比较，如果不一致就报错

该方案只是初步设想，还需要社区专家给出更多意见

6. 预计修复问题时间

【日志信息】(请附上日志文件、截图、coredump信息):


【测试代码】:

见操作步骤

<!-- #请认真填写以下信息，否则可能由于无法定位，导致issue无法解决而被取消 -->

【标题描述】:并发执行和修改A风格存储过程，存在宕机的可能性

【测试类型：SQL功能】【测试版本：7.0.0-RC1】 并发执行和修改A风格存储过程，存在宕机的可能性

【操作系统和硬件信息】(查询命令: cat /etc/system-release, uname -a): x86 + centos7

【测试环境】(单机/1主x备x级联备): 单机

【被测功能】: SQL语法

【测试类型】: 功能测试

【数据库版本】(查询命令: gaussdb -V):


【预置条件】: 无

【操作步骤】(请填写详细的操作步骤):

1. 初始化实例，并创建存储过程，然后重启进程

```

create or replace procedure proc1_1258266(col1 date,col2 inout timestamp,col3 out date)

as

begin

col2:=col2+10;

col3:=col1+15;

end;

/

call proc1_1258266('2023-1-1','2024-1-1 11:15:12',null);

```

2. 登录两个新会话，两个会话预先输入以下sql命令，并且不要执行

会话1

```

call proc1_1258266('2023-1-1','2024-1-1 11:15:12',null);

```

会话2

```

create or replace procedure proc1_1258266(col1 varchar,col2 inout varchar,col3 out text)

as

begin

col2:=length(col2)+10;

col3:=length(col1)+15;

end;

/

```

3.使用gdb调试，如下图操作


4.打断点，线程3是会话1所在的线程


第3个断点依据实际代码行数打上，参考代码，目的是为了观察proc_source这一字符串变量


5.执行会话1的语句，此时会阻塞在断点1，如下图操作，先切换到线程3，然后执行两次finish，让sql命令执行一小段


6.执行会话2，修改存储过程，会话2的命令会顺序完成

7.在gdb执行continue命令，当执行到断点3时，可以打印proc_source，此时proc_source是修改后的存储过程的prosrc,继续执行下去会发生宕机


【预期输出】:

不会宕机，并且报错

【实际输出】:

宕机

【原因分析】:

1. 这个问题的根因

语义分析阶段，会根据实际的函数/存储过程声明，把参数表达式转换为目标参数类型的表达式，这一处理见ParseFuncOrColumn->make_fn_arguments，即此时会确定入参表达式的类型。发生宕机的原因是，语义分析阶段已经把参数确定为日期类型的常量。但语义解析后，其他会话的事务修改了函数定义，并且把参数类型修改了，同时由于本会话后续消费了无效消息，函数编译时(见plpgsql_compile函数)读取了新版本的函数定义，导致把日期类型的表达式作为textlen函数的入参，textlen函数把日期类型的表达式作为字符类型表达式处理，发生宕机。

1）core文件中toastpointer指针值比较诡异，且无法转成varattrib_1b类型后无法打印


2）正常情况下toastpointer，可以打印header


3）把core文件里的变量按照Const来打印(ExecMakeTableFunctionResult函数)，其类型是1114，即timestamp，可以推断，有可能是解析参数是还是按照旧版本的元数据来解析，但是执行时使用了新版本的源数据库，导致把日期类型的表达式作为textlen函数的入参，发生宕机

2. 问题推断过程

3. 还有哪些原因可能造成类似现象

4. 该问题是否有临时规避措施

5. 问题解决方案

考虑以下一个方案：

FunctionCallInfo结构能否增加一个版本号，在plpgsql_exec_function函数内，与PLpgSQL_function.fn_xmin比较，如果不一致就报错

该方案只是初步设想，还需要社区专家给出更多意见

6. 预计修复问题时间

【日志信息】(请附上日志文件、截图、coredump信息):


【测试代码】:

见操作步骤