pg_attribute

问题现象：

客户现场跑业务出现持续coredump。coredump损坏。通过查看寄存器与反汇编得到疑似堆栈

【】

定位过程：

客户启动业务。gdb住数据库，再疑似堆栈heap_fill_tuple上打断点，但调用太多了，想通过其他堆栈预先过滤，也不好用，最终失败。

客户排查业务，逐一进行尝试，找到失败SQL，是个普通的二表join。

【SQL】

启动数据库，执行SQL，发现确实失败。

预先打断点到heap_fill_tuple，停在memcpy_s之前。查看入参。 dest没有问题，刚申请的；src是一个varlena，解析出来长度，发现不对劲，打印src内存如下：

【图】

询问此条SQL以及相关的表、索引最近是否有过变动：表再周四添加了几列，SQL再周五添加了四列的查询，之后就开始core了。

化简SQL，单独查询周五添加的几列，发现会core。定位到其中一列。这一列不查就没事，查就不行。

查询pg_attribute，发现这一列的attinitdefault列值有问题，过长，且与之前gdb打印出来的内容一致。

梳理这列相关的信息：

1、alter table 添加列，并带有默认值''  (客户提供的ddl中是默认值)

2、SQL直接查询就会失败

本地使用B插件进行SQL编写复现：

create table a(a int);

alter table a add column b char(4) default '';

select * from a;

复现失败。

通过函数pg_get_tabledef()发现这一列表的默认值为‘120’，与客户提供的不符合。怀疑客户还做过修改默认值的操作。本地尝试，复现。

create table a(a int);

alter table a add column b char(4) default '';

alter table a modify column b default '120';

select * from a;

但是化简后的SQL有完整的堆栈。堆栈并未损坏。

使用不化简的SQL，二表join，堆栈也会损坏。

在最新master代码仓不复现。对比代码，找到修复用例。

为什么二表join时堆栈损坏的原因最终也没有找到。怀疑与memcpy写的太长，从堆区写超到了栈区有关系。但多次复现，查看堆栈帧的地址，也不是。

方法整理：

寄存器与反汇编：

寄存器sp内存储的是最近的函数指令，查看得到地址，之后使用disassemble命令，可以在代码区找到函数名。

胡正超/devkit