私は現在、pgTapを使用して、かなり大量のPostgreSQLストアドプロシージャに単体テストを追加しています。
一部のプロシージャは、行を明示的にロックする操作を実行します。これらのロックは、アプリケーションにとって重要です。
ロックする必要のある行がロックされていることと、ロックされるべきではない行がロックされていないことを確認するテストを作成するにはどうすればよいですか？
私が現時点で持っている唯一の「手がかり」はpgrowlocks拡張機能です。これにより、トランザクションは別のトランザクションによってロックされた行をチェックできます。ただし、現在のトランザクションには独自のロックがないように見えるため、2つのトランザクションを同期するために何かを使用する必要があります。かなり間違えない限り、pgTapを使用してそれを行う方法はありません。
（注：PostgreSQL 9.1を使用）
問題の行のctidを識別でき、どのトランザクションで行をロックする必要があるかがわかっている場合は、pageinspect拡張機能を使用して、タプル情報フラグとxmaxを確認できますか？情報フラグは、行がロックされていることを示し、xmaxはそれを保持しているトランザクションIDに設定されている必要があります。
ロックする必要のある行がロックされていることと、ロックされるべきではない行がロックされていないことを確認するテストを作成するにはどうすればよいですか？
別のトランザクションを開き、NOWAITで同じ行をロックして、例外をキャッチしてください。
PostgreSQLは自律トランザクションをサポートしていないため、PgTAPテスト内から個別のトランザクションを開くには、dblinkまたは他の同様の拡張機能を使用する必要があります。
PS。Robert Haasが説明しているこのリンクを見つけました。なぜ、行レベルのタプルがpg_locksで追跡されないのですか。
（...）許可されていないタプルロックはpg_locksに表示されますが、許可されると消えます。（これを行わなかった場合、PostgreSQLは中規模のSELECT FOR UPDATEクエリでもロック表スペースを使い果たします。）
一方、ロックの存在をテストする理由がよくわかりませんが、LOCKコマンドが成功すると保証されます。