代码拉取完成，页面将自动刷新
【标题描述】: 开启enable_snapshot之后进行压测数据库连接超时
【测试类型：SQL功能/存储功能/接口功能/工具功能/性能/并发/压力长稳/故障注入/安全/资料/编码规范】【测试版本：5.0.0】 问题描述
【操作系统和硬件信息】(查询命令: cat /etc/system-release, uname -a):
Centos7
【测试环境】(单机/1主x备x级联备):
单机
【被测功能】:
【测试类型】:
压力测试
【数据库版本】(查询命令: gaussdb -V):
【预置条件】:
【操作步骤】(请填写详细的操作步骤):
内部自动化测试发现，只要开启enable_wdr_snapshot就是必现。没法提供详细的复现步骤
【预期输出】:
数据库正常执行
【实际输出】:
数据库执行数小时后，gsql无法连接。经过分析，提供导致数据库阻塞的两个线程堆栈，thread55为snapshot线程，thread56为snapshot起的worker线程。
【原因分析】:
这个instrSnapshotCancel的执行时机不太合理。按理说，此时设置一下参数，不做过多操作，等待下一次check_for_interrups的时候再做处理，应该更合适一些把？
【日志信息】(请附上日志文件、截图、coredump信息):
【测试代码】:
Hey @kenxx, Welcome to openGauss Community.
All of the projects in openGauss Community are maintained by @opengauss_bot.
That means the developers can comment below every pull request or issue to trigger Bot Commands.
Please follow instructions at Here to find the details.
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
Hi @kenxx, please use the command /sig xxx to add a SIG label to this issue.
For example: /sig sqlengine or /sig storageengine or /sig om or /sig ai and so on.
You can find more SIG labels from Here.
If you have no idea about that, please contact with @xiangxinyong , @zhangxubo .
这个问题是在使用dblink时，原有的work线程发生了中断，导致死锁。需要进一步分析。
我们这边分析有几个初步结论，看看能不能参考一下：
1、libpq是一个客户端库，在内核里使用的话，有可能导致这个会话会法马上响应信号中断（CHECK_FOR_INTERRUPTS处理）
2、在信号中断函数die，里面发libpq取消，由于此时postmaster的pmState可能已经进入PM_STOP_BACKENDS、或PM_WAIT_BACKENDS状态，postmaster此时可能无法向应这个libpq取消请求
3、die函数里，也不能做过于复杂的操作，理论上还存在这种情况：该session获得了某个实例级别的锁，这时收到停机信号，代码转跳到die函数，发起libpq取消请求。如果postmaster、或者被取消的线程也需要这把锁，则这时就触发了另一种死锁。详细参考PG的这段说明
因此我们得出一个初步结论：在内核里尽量不要使用libpq这种客户端库，于是，解决方法大概有这几种
1、用其它机制代替libpq，如bgwoker来跨库执行SQL，海量数据库目前采用这种方法解决，但这个方法改动量可能会比较大。
2、die函数里不要直接做取消操作，参考PG的做法，die函数里，仅设置一个中断标记，工作线程等到下一次调CHECK_FOR_INTERRUPTS才处理这个中断。看个改法看起来简单一些，但缺点是无法马上处理信号中断。
3、不要做跨库查询，wdr_xdb_query即可以用普通内置函数实现，从而避免了这个问题，但这个修改可能会影响wdr相关功能
Carl
成员
该问题与contrib/dblink无关
登录 后才可以发表评论
