Test unitaire des verrous de niveau ligne PostgreSQL

Question

J'ajoute actuellement des tests unitaires à une assez grande quantité de procédures stockées PostgreSQL, en utilisant pgTap.

Certaines procédures exécutent des opérations qui verrouillent explicitement les lignes.Ces verrous sont essentiels à l'application.

Comment écrire des tests qui vérifient que les lignes qui doivent être verrouillées l'ont été et que les lignes qui ne devraient pas être verrouillées ne le sont pas?

Le seul "indice" que j'ai pour le moment est l'extension pgrowlocks, qui permet à une transaction de vérifier les lignes verrouillées par une autre transaction.Cependant, la transaction actuelle ne semble pas voir ses propres verrous, donc je devrais utiliser quelque chose pour synchroniser deux transactions, et à moins que je ne me trompe, il n'y a aucun moyen de le faire en utilisant pgTap.

(note: en utilisant PostgreSQL 9.1)

Answer 1

Si vous pouvez identifier le ctid des lignes en question, et savoir quelle transaction devrait avoir les lignes verrouillées, vous pourriez peut-être utiliser l'extension pageinspect et regarder les indicateurs d'information de tuple et xmax?Les indicateurs d'informations doivent indiquer que la ligne est verrouillée et que xmax doit être défini sur l'identifiant de transaction qui la contient.

Answer 2

Comment écrire des tests qui vérifient que les lignes qui doivent être verrouillées l'ont été et que les lignes qui ne devraient pas être verrouillées ne le sont pas?

Ouvrez une transation séparée, essayez de verrouiller la même ligne avec NOWAIT et interceptez l'exception.

PostgreSQL ne prend pas en charge les transactions autonomes, donc - pour ouvrir une transaction distincte à partir du test PgTAP, vous devrez recourir à dblink ou une autre extension similaire.

PS. J'ai trouvé ce lien, où Robert Haas explique pourquoi les tuples de niveau ligne ne sont pas suivi dans pg_locks :

(...) les verrous de tuple non accordés apparaissent dans pg_locks, mais ils disparaissent une fois accordés. (PostgreSQL serait épuisé d'espace de table verrouillé même sur une requête SELECT FOR UPDATE de taille moyenne si nous ne l'avons pas fait.)

D'un autre côté - je ne comprends pas du tout pourquoi vous voulez tester l'existence d'un verrou - c'est garanti après une commande LOCK réussie.