我正在研究一组PL/Python存储过程。我使用的是PostgreSQL 9.3 (从apt.postgresql.org安装)和Python2.7解释器;运行在Ubuntu13.04上。
该错误发生在一个大型操作的中间(创建一个物化视图,该视图使用的数据来自超过30万行的源表,并使用PL/Python存储过程计算某些字段)。
我得到的错误输出是:
ERROR: could not convert SPI error to Python exception
CONTEXT: PL/Python function "get_first_level_parent"
********** Error **********
ERROR: could not convert SPI error to Python exception
SQL state: XX000
Context: PL/Python function "get_first_level_parent"("get_first_level_parent“是一个存储过程的名称)。
PostgreSQL服务器日志没有提供任何进一步的说明(我不熟悉PostgreSQL和PL/Python )。当使用详细的错误日志运行时,我得到以下内容:
2013-10-18 12:56:43 EAT ERROR: XX000: could not convert SPI error to Python exception
2013-10-18 12:56:43 EAT CONTEXT: PL/Python function "get_first_level_parent"
2013-10-18 12:56:43 EAT LOCATION: PLy_spi_exception_set, plpy_spi.c:576PostgreSQL错误代码文档告诉我,XX000是internal_error的错误代码。如果我隔离对存储过程的调用,并在它自己的语句(如SELECT get_first_level_parent(373673007) )中运行它,它不会引发错误。
我的问题是-我可以使用哪些工具/技术来调试这类错误?对于我当前的问题,我可能会通过重写存储过程来“解决”这个问题(慢慢地,一次测试一个小部分)。这是唯一的出路吗?
发布于 2013-10-18 14:28:21
我会在src/pl/plpython/plpy_spi.c:PLy_spi_exception_set()中添加一些调试语句。这可能是PL/Python在处理某些边缘条件时的一个错误。
发布于 2013-10-19 07:58:00
在存储过程中添加了大量的plpy.notice(...语句之后,我最终分离出了一个可靠地再现错误的SQL存储过程调用。
这里的罪魁祸首是我编写的PL/Python过程中的边缘案例。我在其中一个存储过程中有一个递归算法。递归的使用是由问题域决定的。在所有正常操作条件下,递归不会超过10-12深度(输入的数据是众所周知且相对静态的)。在某些情况下,我的实现中有一个错误导致无限递归。
PL/Python似乎并不是用来处理超过最大递归深度时发生的RuntimeError。这可能是一个非常罕见的边缘情况。
https://stackoverflow.com/questions/19447004
复制相似问题