开发者社区 问答 正文

求助,在pg 11 的 procedure中 如果 使用 mysql_fdw外部表导致崩溃。

求助,在pg 11 的 procedure中 如果 使用 mysql_fdw外部表导致崩溃。
我们有个procedure,使用到了 mysql_fdw外部表,这个 procedure 被重复调用几次后,(在我们这台PG上)第7次调用,产生"An I/O error occurred while sending to the backend.",在 server的log中也产生下下面的错误输出:
server process (PID 6275) was terminated by signal 11: Segmentation fault","Failed process was running: call xxx.sp_xxx_xx('2018-12-20','2018-12-21')",,,,,,,"LogChildExit, postmaster.c:3579.

这导致了整个数据库的重启“The postmaster has commanded this server process to roll back the current transaction and exit”。

请问大家,有没有遇到过这种情况,如果这个是BUG的化,有没有修复方法?

我们手动 重复执行 对应的SQL,重复多次,不会出现这个问题。使用DO 块执行多次也不会出现,就是 在 PROCEDURE中 调用的化,会出现这个问题。
本问题来自云栖社区【PostgreSQL技术进阶社群】。https://yq.aliyun.com/articles/690084 点击链接欢迎加入社区大社群。

展开
收起
游客886 2019-04-25 17:09:33 2222 分享 版权
阿里云 AI 助理回答

遇到您描述的问题,看起来是PostgreSQL在使用mysql_fdw(一个用于访问MySQL数据库的外部数据包装器)时出现了不稳定情况,特别是在存储过程(procedure)中调用时导致了段错误(Segmentation fault)。这可能是由于几个原因造成的,包括但不限于:

  1. 兼容性或bug:可能存在的一个原因是mysql_fdw与PostgreSQL 11之间的兼容性问题或者是一个已知的bug。建议查阅mysql_fdw的官方文档或GitHub仓库,确认是否有其他用户报告了类似问题,并查看是否有修复版本或补丁可用。

  2. 资源限制或内存泄漏:频繁调用过程中出现段错误可能是因为内存管理问题,比如内存泄漏或资源限制达到上限。检查是否在存储过程中正确处理了资源释放,以及PostgreSQL和系统级别的资源限制设置是否合理。

  3. PostgreSQL配置:确保PostgreSQL的配置参数(如shared_bufferswork_mem等)适合您的工作负载,避免因资源配置不足导致的异常。

  4. 日志详细级别:将PostgreSQL的日志详细级别设置为更详细的级别(如log_min_messages = debug1),以便收集更多关于错误发生前后的信息,这有助于诊断问题。

  5. 升级或降级测试:如果条件允许,可以尝试在不同的PostgreSQL版本上复现该问题,看是否特定版本导致。有时,升级到最新稳定版或回退到一个已知稳定的版本能解决问题。

  6. 社区与官方支持:鉴于问题来自阿里云的PostgreSQL技术进阶社群,建议直接在社群内寻求帮助或联系阿里云的技术支持团队。他们可能会有针对阿里云环境下的特定解决方案或已知问题的内部记录。

  7. 替代方案:如果问题持续且无法快速解决,考虑是否有替代方案来实现相同功能,比如通过应用程序层面进行数据同步而非直接在存储过程中跨数据库查询。

请记得,在进行任何配置更改或升级之前,备份您的数据库以防不测。希望这些建议对您有所帮助!

有帮助
无帮助
AI 助理回答生成答案可能存在不准确,仅供参考
0 条回答
写回答
取消 提交回答