2

PL/Python ストアド プロシージャのセットに取り組んでいます。私は PostgreSQL 9.3 ( apt.postgresql.org からインストール) と Python 2.7 インタープリターを使用しています。Ubuntu 13.04 で実行されています。

このエラーは、大規模な操作の途中で発生します (300,000 行を超えるソース テーブルのデータを使用するマテリアライズド ビューを作成し、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」はストアド プロシージャの 1 つの名前です)。

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:576

PostgreSQL エラー コードのドキュメントによると、これXX000は のエラー コードですinternal_error。ストアド プロシージャへの呼び出しを分離し、独自のステートメントで実行するとSELECT get_first_level_parent(373673007)、エラーは発生しません。

私の質問は、この種のエラーをデバッグするために使用できるツール/テクニックは何ですか? 私の現在の問題については、ストアドプロシージャを書き直すことで問題を「解決」する可能性があります（ゆっくりと、一度に1つの小さな部分をテストします）。それが唯一の方法ですか？

4

2 に答える 2

2

にいくつかのデバッグ ステートメントを振りかけsrc/pl/plpython/plpy_spi.c:PLy_spi_exception_set()ます。これは、エッジ条件の処理における PL/Python のバグである可能性があります。

于 2013-10-18T14:28:21.853 に答える
1

ストアド プロシージャにステートメントを多めに散りばめた後plpy.notice(...、最終的に、エラーを確実に再現する単一の SQL ストアド プロシージャ呼び出しを分離しました。

ここでの犯人は、私が書いた PL/Python プロシージャの 1 つのエッジ ケースでした。ストアド プロシージャの 1 つに再帰アルゴリズムがあります。再帰の使用は、問題のドメインによって決まります。すべての通常の操作条件下では、再帰は 10-12 の深さを超えることはありません (入力データはよく知られており、比較的静的です)。私の実装には、状況によっては無限再帰につながるバグがありました。

RuntimeErrorPL/Python は、最大再帰深度を超えたときに発生するを処理するように設定されていないようです。これはおそらく非常にまれなエッジ ケースです。

于 2013-10-19T07:58:00.093 に答える