PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Contrôle de la durée des attentes de verrouillage PostgreSQL

Non. FOR UPDATE verrouille uniquement ces lignes , afin qu'une autre transaction qui tente de les verrouiller (avec FOR SHARE , FOR UPDATE , UPDATE ou DELETE ) bloque jusqu'à ce que votre transaction soit validée ou annulée.

Si vous voulez un verrou de table entier qui bloque les insertions/mises à jour/suppressions, vous voudrez probablement LOCK TABLE ... IN EXCLUSIVE MODE .

  1. Voir le lock_timeout réglage . Cela a été ajouté dans la version 9.3 et n'est pas disponible dans les anciennes versions.

    Des approximations brutes pour les anciennes versions peuvent être obtenues avec statement_timeout , mais cela peut entraîner l'annulation inutile de relevés. Si statement_timeout est de 1 s et qu'une instruction attend 950 ms sur un verrou, elle peut alors obtenir le verrou et continuer, pour être immédiatement annulée par un délai d'attente. Pas ce que vous voulez.

    Il n'y a aucun moyen au niveau de la requête de définir lock_timeout , mais vous pouvez et devrait juste :

    SET LOCAL lock_timeout = '1s';

    après avoir BEGIN une transaction.

  2. Il y a une déclaration timeout, mais les verrous sont maintenus à transaction niveau. Il n'y a pas de fonctionnalité de délai d'expiration des transactions.

    Si vous exécutez des transactions à instruction unique, vous pouvez simplement définir un statement_timeout avant d'exécuter l'instruction pour limiter la durée d'exécution. Ce n'est pas tout à fait la même chose que de limiter la durée pendant laquelle il peut maintenir un verrou, car il peut attendre 900 ms sur 1 s autorisées pour le verrou, ne maintenir le verrou que pendant 100 ms, puis être annulé par le délai d'attente.

  3. Non. Vous devez :

    BEGIN;
SET LOCAL lock_timeout = '4s';
SELECT ....;
COMMIT;

  4. SET LOCAL est approprié, et préféré, pour cela.

    Il n'y a aucun moyen de le faire dans le texte de la requête, il doit s'agir d'une instruction distincte.

    Le message de la liste de diffusion auquel vous avez lié est une proposition de syntaxe imaginaire qui n'a jamais été implémentée (du moins dans une version publique de PostgreSQL) et n'existe pas.

Dans une situation comme celle-ci, vous voudrez peut-être envisager un "contrôle de concurrence optimiste", souvent appelé "verrouillage optimiste". Cela vous donne un meilleur contrôle sur le comportement de verrouillage au prix d'un taux accru de répétition des requêtes et du besoin de plus de logique d'application.