サポートしようとしているアプリケーションで、現在、一意の制約違反が発生しています。非実稼働環境でこの問題を再現できませんでした。デバッグ目的で、実際にはすべての挿入を別のテーブルにコピーするルール (トリガー?) を作成することは合理的ですか? したがって、事実上、新しいテーブルは制約なしで古いテーブルと同じになることを願っています。
このアプリケーションは Spring を使用してトランザクションを管理していますが、ルールとトランザクションに関するドキュメントは見つかりませんでした。違反の後、それまでにトランザクションに書き込まれたものはすべてロールバックされます。これは何らかの形でルールに影響しますか? これは Postgres 8.3 です。
ルールとトリガーを使用して、想像できるほとんどすべてのことを行うことができます。そして、もう少し。ただし、あなたの正確な意図はやや不明なままです。
とにかくトランザクションがロールバックされた場合、最後に示唆したように、関連するルールまたはトリガーのすべての副作用を含め、すべてが元に戻されます。あなたの計画は無駄です。
それが実際に達成したい場合の回避策があります。dblinkを使用して、同じデータベース内のテーブルにリンクし、INSERT します。それはロールバックされていません。
ただし、デバッグ目的のみの場合は、データベース ログを使用すると、どの重複が入力されていないかを簡単に確認できます。エラーはデフォルトでログに記録されます。そうでない場合は、必要に応じて設定できます。オプションについては、マニュアルを参照してください。
違反の後、それまでにトランザクションに書き込まれたものはすべてロールバックされます。これは何らかの形でルールに影響しますか?
これにより、ルールが行ったすべてのこともロールバックされます。dblinkを使用するトリガーを作成して、現在のトランザクションの外部で作業を行うことができます。別のオプションはセーブポイントかもしれませんが、現在のコードとトランザクションをすべて変更する必要があります。
固有の違反もログ ファイルに記録されます。この情報を取得して、何が問題なのかを確認してください。バージョン 9.0には、値が何であるかも示す変更があります。
一意性制約違反のエラー メッセージが、失敗の原因となった値を報告するように改善されました。
すでに述べたように、ルールはクエリの書き換えにのみ役立つため、この目的に使用することはできません。ただし、書き直されたクエリは、元のクエリがまだトランザクションの一部であるのと同じです。
ルールを使用して、複数のテーブル間で一意のキーやその他のマルチテーブルのものなど、通常の制約を使用して実装することが不可能な制約を適用できます。（これらには、ログとエラーメッセージに表示される「カナリア」テーブル名の利点があります）しかし、OPにはすでに制約が多すぎるため、表示されます...
シリアル化レベルを微調整することも示されているようです（複数のセッションが含まれていますか？フレームワークは接続プールを使用していますか？）