LOCK

Description

LOCK TABLE contrôle les accès concurents à une table pendant la durée d'une transaction. PostgreSQL utilise toujours le mode de verrouillage le moins restrictif quand c'est possible. LOCK TABLE est fournit pour les cas où vous avez besoin de verrous plus restrictifs.

Le verrouillage des SGBDR utilise la terminologie suivante :

Par exemple, supposons qu'une application lance une transaction au niveau d'isolation READ COMMITTED et ait besoin de s'assurer de l'existence de données dans une table pour la durée de la transaction. Pour ça vous pouvez obtenir le mode de verrouillage SHARE sur la table avant de la questionner. ceci empêchera les modifications de données concurentes et assurera les opérations de lecture ultérieures sur la table voyant les données dans leur état actuel, car le mode de verrouillage SHARE entre en conflit avec les modes de verrouillage ROW EXCLUSIVE acquis par les écritures, et vos instructions LOCK TABLE name IN SHARE MODE attendrons jusqu'à ce que des opérations d'écriture concurentes soient validées ou avortées. Ainsi, une fois obtenu le verrouillage, il n'y a pas d'écritures non-validées marquantes.

Pour lire les données dans leur état actuel quand vous lancez une transaction au niveau d'isolation SERIALIZABLE, vous devez exécuter l'instruction LOCK TABLE avant l'exécution d'une instruction DML. Une vue de transaction sera gelée quand son instruction DML débute en premier.

En plus de ce qui précède, si une transaction modifie les données d'une table, le mode de verrouillage SHARE ROW EXCLUSIVE sera acquis pour pour éviter les conditions de verrous mortels quand deux transactions concurrentes tentent de verrouiller une table en mode SHARE et essaient de modifier les données dans cette table, les deux (implicitement) acquérant le mode de verrouillage ROW EXCLUSIVE qui provoque des conflits avec un verrou LOCK concurrent.

Pour continuer avec le verrou mortel (quand deux transactions attendent une autre), vous devez suivre deux règles générales pour éviter ces conditions:

• Les transactions doivent acquérir des verous sur les mêmes objets dans le même ordre.

  Par exemple, si une application met à jour la ligne R1 et met à jour la ligne R2 (dans la même transaction) alors la seconde application ne pourra pas mettre à jour R2 si R1 est mis à jour plus tard (dans une seule transaction). De même, la mise à jour des lignes R1 et R2 devra se faire dans le même ordre que la première application.

• Les transactions acquerront deux modes de verrouillage conflictuels seulement si l'un d'eux est auto-conflictuel (i.e, peut être maintenu par une seule transaction à un moment). Si de multiples modes de verrouillage sont insérés, alors les transactions acquerront toujours le mode le plus restrictif en premier.

  Un exemple de cette règle a été donné précédemment quand nous parlions de l'utilisation du mode SHARE ROW EXCLUSIVE de préférence au mode SHARE.

Postgres peut détecter les verrous mortels et avortera au moins une transaction en attente pour résoudre le verrou mortel.

Lors du verrouillage de plusieurs tables, la commande LOCK a, b; est équivalente à LOCK a; LOCK b;. Les tables sont verrouillées une par une dans l'ordre spécifié dans la commande LOCK.

Utilisation

Illustration d'un verrou SHARE sur une table à clé primaire en exécutant des insertions dans une table à clé étrangère :

BEGIN WORK;
LOCK TABLE films IN SHARE MODE;
SELECT id FROM films 
    WHERE name = 'Star Wars: Episode I - The Phantom Menace';
-- Do ROLLBACK if record was not returned
INSERT INTO films_user_comments VALUES 
    (_id_, 'GREAT! I was waiting for it for so long!');
COMMIT WORK;
   

Prend un verrou SHARE ROW EXCLUSIVE sur une table à clé primaire en exécutant une opération de suppression :

BEGIN WORK;
LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE;
DELETE FROM films_user_comments WHERE id IN
    (SELECT id FROM films WHERE rating < 5);
DELETE FROM films WHERE rating < 5;
COMMIT WORK;
   

Compatibilité