2010-03-06 7 views
29

Dans SQLServer, vous pouvez utiliser la syntaxe "(nolock)" pour vous assurer que la requête ne verrouille pas la table ou n'est pas bloquée par d'autres requêtes qui verrouillent la même table. par exemple.PostgreSQL Equivalent de l'indicateur NoLock de SQLServer

SELECT * FROM mytable (nolock) WHERE id = blah 

Quelle est la syntaxe équivalente dans Postgres? J'ai trouvé de la documentation sur le verrouillage de la table dans PG (http://www.postgresql.org/docs/8.1/interactive/sql-lock.html), mais tout semble axé sur comment verrouiller une table, pas s'assurer que c'est non verrouillé.

+1

Attendez, laissez-moi voir si je comprends cela. Il y a une option pour ignorer les verrous sur une table ??? Si vrai, c'est une mauvaise idée qui se classe là-haut avec l'option d'ignorer les lignes existantes lors de la validation de nouvelles contraintes. –

+3

@Matthew Wood: En général, je serais d'accord. Cependant, ignorer les verrous est utile dans certains cas, comme le débogage lorsque vous voulez inspecter le contenu d'une table même si c'est au milieu d'une très grande mise à jour. Ignorer le verrou est préférable d'attendre plusieurs minutes/heures pour la mise à jour à compléter. – Cerin

Répondre

38

A SELECT ne se verrouille pas une table dans PostgreSQL, sauf si vous voulez un verrou:

SELECT * FROM tablename FOR UPDATE; 

PostgreSQL utilise MVCC pour minimiser la contention de verrouillage afin de permettre la performance raisonnable dans des environnements multi-utilisateurs. Les lecteurs ne sont pas en conflit avec les écrivains ni avec les autres lecteurs.

4

J'ai effectué quelques recherches et il semble que l'indicateur NOLOCK dans SQL Server soit à peu près le même que le niveau d'isolation de transaction READ UNCOMMITTED. Dans PostgreSQL, vous pouvez définir READ UNCOMMITTED, mais il met silencieusement à niveau le niveau READ COMMITTED. READ UNCOMMITTED n'est pas supporté.

documentation PostgreSQL 8.4 pour l'isolement de la transaction: http://www.postgresql.org/docs/8.4/static/transaction-iso.html

+4

Une petite citation pour en souligner la cause: _La raison pour laquelle PostgreSQL ne fournit que deux niveaux d'isolation est que c'est la seule manière sensée de mapper les niveaux d'isolation standard à l'architecture de contrôle d'accès concurrentiel multiversion._ – dezso

+3

@dezso: +1, mais dans 9.1 SERIALIZABLE a été ajouté, de sorte que les documents ont été mis à jour pour dire "... fournit trois niveaux d'isolement ..." mais est par ailleurs le même. –